On Friday 07 March 2003 08:27 am, you wrote: > This is a good explanation, thanks! After your comment I checked man > chmod, I guess the explanation below is what you are referring to: > > STICKY DIRECTORIES > When the sticky bit is set on a directory, files in that directory may > be unlinked or renamed only by root or their owner. Without the sticky > bit, anyone able to write to the directory can delete or rename files. > The sticky bit is commonly found on directories, such as /tmp, that are > world-writable.
No, that's a way around a particular permissions problem. The problem comes up in a couple of ways, the simple one here where multiple people have write access to a common directory. Having the ability to create a file in a directory means that you also have the ability to remove a file (properly, the link to the inode) from that directory - thus *anyone's* files. The 'sticky bit' (properly the 'set user id on execute' or 'set groupd id on execute' function didn't have a use on a directory, since it's not directly executable (and the execute bit is already used for 'ability to search') so the BSD folks set this up some years ago and it migrated into Linux. Where this is particularly handy is in the mail directories - common areas where you want to manage your files but not let others read or delete them, unless they're a member of the mail group. File permissions and handling are critical to a number of applications and the very best reason to never, ever, run with root permissions as a regular user. I used to run into that all the time - folks would get tired of permission issues and start running printer demons as root and get all screwed up because there it blew away the printer and queue arbitration as it used the creation of read-only files as an atomic semaphore (the only one available in NFS).
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
