Messages in this thread | | | Date | Mon, 11 Oct 1999 15:34:14 -0600 | From | Richard Gooch <> | Subject | Re: Other $0.02 on devfs permission persistance |
| |
David Harris writes: > The devfs FAQ seems to indicate in the section "Persistence of > ownership/permissions across reboots" that the rc.devfs script is > required to make permission modifications made through chmod(2) > stick. It also seems to say that permissions _should_ be modified > using the configuration file, which gives the user more control and > is naturally persistent over reboots. But if the permissions are > modified with chmod(2) then rc.devfs is required for persistence. Is > this true?
No, you can use devfsd instead. You can configure it to chmod(2) an inode on a disc-based FS whenever something chmod(2)s an entry in devfs. This is almost exactly the same configuration that you'd use to manage a disc-based /dev while mounting devfs on /devices.
Or you could write a script that updates your own purpose-built permissions database. It's up to you. All the infrastructure is already there.
> If so that seems kind of annoying. I'd prefer that permission > modifications made with chmod(2) stick even if the system crashes > and the background user-space daemon was never started. It seems > that the problem is having devfs store _any_ information in memory > that we want to eventually become persistent and stored to disk > (either by some script on shutdown or the devfsd) .
So configure your system to do what you want. No problem.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |