david@wubios.wustl.edu (David J. Camp) (02/08/89)
We have a strange situation where a program can write to a file even though it does not have write permission. What it does is remove the file and write a new one in its place. It can do this because it has write permission to the directory in which the file is contained. My question is: What is the (historical or otherwise) justification for this rule? It seems wrong. I would have required write permission to the file itself in order that it be removed. -David- -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University Medical School Saint Louis, MO 63110
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/09/89)
In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: >My question is: What is the (historical or otherwise) justification for >this rule? It seems wrong. I would have required write permission to >the file itself in order that it be removed. I don't know what you think of when you say "file", so let's talk about inodes instead. One does NOT need to "write" (i.e. modify) the contents of an inode in order to remove the link to it from another (directory) inode, but one DOES need to be able to modify the directory inode. In other words, it works and makes sense, but you have to have the right mental model of the UNIX hierarchical file system.
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (02/09/89)
In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: .>We have a strange situation where a program can write to a file even .>though it does not have write permission. What it does is remove the .>file and write a new one in its place. It can do this because it has .>write permission to the directory in which the file is contained. .>My question is: What is the (historical or otherwise) justification for .>this rule? It seems wrong. I would have required write permission to .>the file itself in order that it be removed. In order to disallow 'removal-of-file' positions, you must remove write protection from the directory. By removing a file, you are not writing to the file, or altering it in ANY way, you are merely removing the link to the file, which means you are writing to the directory which has that link. -- |\/| | | | _ |< / \_(_(_)\_/ \______
denbeste@bgsuvax.UUCP (William C. DenBesten) (02/09/89)
From article <306@wubios.wustl.edu>, by david@wubios.wustl.edu (David J. Camp): > We have a strange situation where a program can write to a file even > though it does not have write permission. What it does is remove the > file and write a new one in its place. It can do this because it has > write permission to the directory in which the file is contained. > > My question is: What is the (historical or otherwise) justification for > this rule? It seems wrong. I would have required write permission to > the file itself in order that it be removed. When you remove a file, what you really are doing is edit the directory so that the file is no longer in it. Hence, you need write permission on the directory. You are not making any changes to the contents of the file, so you don't need to be able to write to the file. After you remove the file, the kernel notices that there is a file that is not in any directory and frees up the space. This has been simplified just a tad. -- William C. DenBesten denbeste@bgsu.edu
dik@uva.UUCP (Casper H.S. Dik) (02/11/89)
In article <1995@lindy.Stanford.EDU> eirik@lurch.Stanford.EDU (Eirik Fuller) writes: >All this chatter about how somone else can remove my file even if I'm >the only one who can write to it got me thinking, and the solution is >obvious. .... If you have 4.3BSD, SunOS 4.x etc the solution is even more obvious: Set the sticky bit on your directory. This prevents people other than the owner of the file or the owner of the directory in which the link resides to unlink or rename the link. E.g.: 'chmod +t' /tmp prevents nasty people from doing 'chdir /tmp ; rm -f *' --cd ---------------------------------------------------------------------------- Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik
leo@philmds.UUCP (Leo de Wit) (02/12/89)
In article <632@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes: |If you have 4.3BSD, SunOS 4.x etc the solution is even more obvious: |Set the sticky bit on your directory. This prevents people other than |the owner of the file or the owner of the directory in which the link |resides to unlink or rename the link. A pity (is it really?) that ordinary users are not allowed to set 'sticky mode', this makes it hard to use by anyone but root. I fail to understand what the possibility of unlinking has to do with sticky bits (but then, you can fill me in); I thought that a sticky bit keeps a file on the swap disk, once it is loaded. If a user can put a file in a directory (write the directory file) he can also remove ANY file in that directory (he can write the directory file, so delete any links in that file). The only exception I can think of, are non-empty subdirectories of the directory. And that is the way I put stuff in /tmp that should not be removed by others: $ cd /tmp $ mkdir leo $ chmod 700 leo $ >leo/.guard Leo.
jon@jonlab.UUCP (Jon H. LaBadie) (02/12/89)
This is a future direction of UNIX question. I stumbled upon a system with /tmp directory permissions as follows: drwsrwxrwx ...... Note the "s". Turns out, the system had a "research facility" added to the kernel, namely a meaning for the set user id bit on directories. The meaning? Kind of neat! Anyone could create files in the directory, but only the owner of the directory, OR the owner of the individual files could remove them. It was not simply a root facility either, I could create similar directories and anyone could write to them, but could not remove anything except their own stuff. You can imagine the egg on my face when, in an Intro. to UNIX class, I tried to "prove" that anyone could remove files from a writable/executable directory with a demo during the lecture. So, the questions: 1. Anyone know of the future fate of this useful tweak? 2. Anyone know of any problems with this idea that suggest it should not be implemented?
dik@uva.UUCP (Casper H.S. Dik) (02/13/89)
In article <950@philmds.UUCP} leo@philmds.UUCP (Leo de Wit) writes: }In article <632@uva.UUCP> dik@uva.UUCP (Casper H.S. Dik) writes: }|If you have 4.3BSD, SunOS 4.x etc the solution is even more obvious: }|Set the sticky bit on your directory. This prevents people other than }|the owner of the file or the owner of the directory in which the link }|resides to unlink or rename the link. } }A pity (is it really?) that ordinary users are not allowed to set }'sticky mode', this makes it hard to use by anyone but root. I fail to }understand what the possibility of unlinking has to do with sticky bits }(but then, you can fill me in); I thought that a sticky bit keeps a }file on the swap disk, once it is loaded. } Well it used to be only effective on executables. But with 4.3BSD(?) came the sticky bit for directories. Every user can set the sticky bit of a directory. Apparently someone somewhere noticed an unused bit in the mode word for directories. (With SunOS 4.x, I understand, you can even make directories setuid or setgid) The name sticky still is appropriate because files 'stick' to the directory they are in. This feature is new, so few people know about it (I think). sticky(8) from SunOS 3.5 says: A directory for which the `sticky bit' is set restricts deletion of files it contains. A file in a sticky directory may only be removed or renamed by a user who has write per- mission on the directory, and either owns the file, owns the directory, or is the super-user. This is useful for direc- tories such as /tmp, which must be publicly writable, but which should deny users access to arbitrarily delete or rename the files of others. Any user may create a sticky directory. Only the super-user can set the sticky bit on a non-directory file. } Leo. --cd ---------------------------------------------------------------------------- Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik
guy@auspex.UUCP (Guy Harris) (02/13/89)
>A pity (is it really?) that ordinary users are not allowed to set >'sticky mode', this makes it hard to use by anyone but root. Wrongo. Any user can set the sticky bit on a *directory*, assuming they own it; they're just disallowed from setting it on plain files. >I fail to understand what the possibility of unlinking has to do with >sticky bits It has nothing to do with sticky bits. >(but then, you can fill me in); I thought that a sticky bit keeps a >file on the swap disk, once it is loaded. That notion obviously means nothing for directories, so the "sticky bit" could be overloaded to mean one thing on directories and another thing on plain files. Berkeley (and, subsequently, AT&T, in S5R3.2) decided to do so, in order to permit you to make "/tmp", or other directories, directories in which people can create files, but from which only the owner can remove a file.
guy@auspex.UUCP (Guy Harris) (02/13/89)
>This is a future direction of UNIX question. Not future any more; see below. > 1. Anyone know of the future fate of this useful tweak? It's implemented in 4.3BSD and System V Release 3.2, as well as systems derived from either or both of those systems; the only difference is that it uses the "sticky" bit rather than the "set-UID" bit.
scm@datlog.co.uk ( Steve Mawer ) (02/13/89)
In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: >We have a strange situation where a program can write to a file even >though it does not have write permission. > I would have required write permission to >the file itself in order that it be removed. >-David- I too, have thought this behaviour bizarre. However, the (logical) answer is that deleting a file does *not* involve writing to it, only to the directory. Therefore, if you can write to a directory, you can delete the file. If you want to protect your files, match the permissions of the file with those of the directory. (I know this is not a good answer if you want users to be able to *create* personal files in the directory.) -- Steve C. Mawer <scm@datlog.co.uk> or < {backbone}!ukc!datlog!scm > Voice: +44 1 863 0383 (x2153)
prc@maxim.ERBE.SE (Robert Claeson) (02/14/89)
In article <9627@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: > >My question is: What is the (historical or otherwise) justification for > >this rule? It seems wrong. I would have required write permission to > >the file itself in order that it be removed. > I don't know what you think of when you say "file", so let's talk > about inodes instead. One does NOT need to "write" (i.e. modify) > the contents of an inode in order to remove the link to it from > another (directory) inode, but one DOES need to be able to modify > the directory inode. I think that what David meant is that it would make more sense to let all objects in the file system have its own attributes, instead of relying on the directory permissions for some things. And I agree -- it certainly makes more sense to have a "delete" attribute on a file, which must be set in order for me to remove it. And I'd like to add an "append" attribute to the list. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
richard@aiai.ed.ac.uk (Richard Tobin) (02/14/89)
In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: >We have a strange situation where a program can write to a file even >though it does not have write permission. What it does is remove the >file and write a new one in its place. It can do this because it has >write permission to the directory in which the file is contained. > >My question is: What is the (historical or otherwise) justification for >this rule? It seems wrong. I would have required write permission to >the file itself in order that it be removed. In Unix, a file has an existence separate from a directory entry that refers to it. Changing the file, and changing a reference to it in a directory, are logically distinct. So it's not surprising that there are separate permissions for the two operations. Of course, the kernel could prevent you from removing a reference to a file you can't write. Why doesn't it? Because it would remove a useful feature. This feature is most apparent when there are multiple references (or "links" as they're usually known) to a single file. Then writing the file has a quite different effect from removing it and creating a new file. Try it: % echo hello > fred % ln fred jane % ls -li fred janeb 571 -rw-r--r-- 2 richard 6 Feb 13 20:20 fred 571 -rw-r--r-- 2 richard 6 Feb 13 20:20 jane ^ ^ | this says there are two links to the file this is the "inode number" of the file, which identifies it uniquely (more or less) % echo xyzzy >fred % cat fred xyzzy % cat jane xyzzy skye% ls -li fred jane 571 -rw-r--r-- 2 richard 6 Feb 13 20:23 fred 571 -rw-r--r-- 2 richard 6 Feb 13 20:23 jane ^ still the same file % rm jane % echo plugh >jane % cat fred xyzzy % cat jane plugh % ls -li fred jane 571 -rw-r--r-- 1 richard 6 Feb 13 20:23 fred 586 -rw-r--r-- 1 richard 6 Feb 13 20:25 jane ^ now they're different files -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
mirk@warwick.UUCP (Mike Taylor) (02/14/89)
In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David Camp) writes: >We have a strange situation where a program can write to a file even >though it does not have write permission. What it does is remove the >file and write a new one in its place. It can do this because it has >write permission to the directory in which the file is contained. > >My question is: What is the (historical or otherwise) justification for >this rule? It seems wrong. I would have required write permission to >the file itself in order that it be removed. Aha! Henry Spencer's classic line strikes yet again: "Those who do not understand UNIX are condemned to re-invent it, poorly". There are no design flaws of this level of simplicity in UNIX (OK, so it's a sweeping statemnt, but that's OK, 'cos it's also a true one (1/2 a :-)) The way UNIX handles these things is about as flexible and intuitive as it is possible to be, (though I'll admit it had me a bit confused when I started off) Think of a directory as a listing of the files that make up its contents. Then to write to the directory is to change this list - ie, to add to it, delete from it, alter a name, change permissions on a file or whatever. To do these things, you need write permission on a directory. To change the actual contents of a file, you need write permission to the file. To do what you suggested above, (ie. removing the file and creating a new one with the same name) might *look* like it's the same file, but is actually a different one. Consider, for example, the fact that the shell "/bin/sh" is (on most systems) owned by root, but in the directory /bin owned by bin. Bin cannot change the shell binary, but can replace it with a new one. However, if this happens, it will be clear to all and sundry that the user with access to the "bin" account has been a naughty boy. (Mind you, we all keep our "bin" accounts nice and secure, don't we? :-) ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs "Some folks lives roll easy as a breeze ... Drifting through a summer night." ------------------------------------------------------------------------------
barmar@think.COM (Barry Margolin) (02/15/89)
In article <502@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: >it certainly makes more sense to have a "delete" attribute on a file, >which must be set in order for me to remove it. But since Unix allows a single file to be accessed using multiple directory entries, a single delete attribute isn't enough. How would you specify that it is OK for anyone to remove some of the links, but not others? For instance, I might make a hard link in my directory to something in a friend's directory. Only I should be allowed to remove my link, and only he should be allowed to remove his link, and he shouldn't be able to prevent me from removing my link. If you're going to allow multiple hard links, as Unix does, then it doesn't make sense for deletability to be a file attribute, it must be a link attribute. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
guy@auspex.UUCP (Guy Harris) (02/15/89)
(Corrected version of previous posting; in S5 releases with mandatory locking, it's the set-GID bit that represents the "mandatory locking" bit, not the sticky bit.) >But with 4.3BSD(?) came the sticky bit for directories. Yup. (Actually, I thought I'd remembered it appearing in some 2.xBSD release at one point, but I think somebody more closely connected with those releases said it wasn't there.) >Apparently someone somewhere noticed an unused bit in the mode word >for directories. (With SunOS 4.x, I understand, you can even make >directories setuid or setgid) SetGID, yes. SetUID, well, you may be able to turn the bit on, but it doesn't do anything. Turning the set-GID bit causes files (and directories) created in that directory to have the group owner of the directory, rather than the effective GID of the process that created them, as their group owner; by default, unless the file system was mounted with the "grpid" option, newly-created files have the effective GID of the process that created them as their group owner. (This was done in order to permit both the old "use the effective GID" semantics for the benefit of any programs from S5 or whatever that depend on it, and the use of the new 4.2BSD-style "use the parent directory's group owner" semantics, which are more convenient. I think S5R4 will have the same mechanism.) In later S5 releases, the setGID bit is used for yet another purpose other than rendering executable files set-GID; if the file is non-executable, and the sticky bit is set, it means "record locks on this file are mandatory", which means that a read lock on a region will block "write"s to a region that overlaps that region, and a write lock on a region will block "read"s or "write"s to a region that overlaps that region.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/16/89)
In article <1177@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes:
[the unix permissions scheme is intuitive because a directory
is a list of files]
There is still a flaw.
If a directory is like the card catalog in a library, and the files
themselves are like the books, then it is counter-intuitive that, when
somebody vandalizes the card catalog, all the books are destroyed too.
In UNIX, the existence of a file under normal circumstances is nearly
synonymous with the existence of its directory entry. In a sense the
directory entry represents the file to the user, since he cannot look
at the file in any other way. It *is* counterintuitive that a
read-only file cannot be written to but can still be deleted.
Thank heavens for the sticky bit on directories. It came just in time,
and does invalidate much of the criticism.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: bsu-cs!dhesi@iuvax.cs.indiana.eduroot@conexch.UUCP (Larry Dighera) (02/16/89)
In article <630@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
<This is a future direction of UNIX question.
<
<I stumbled upon a system with /tmp directory permissions as follows:
<
< drwsrwxrwx ......
<
<Note the "s".
<[...] namely a meaning for the set user id bit on directories.
<The meaning? Anyone could create files in the directory,
<but only the owner of the directory, OR the owner of the individual
<files could remove them.
<So, the questions:
< 1. Anyone know of the future fate of this useful tweak?
At a presentation to the Orange County Unix Users Group last month the
AT&T speaker mentioned that Release 4 will support use of the suid bit
on directories. He didn't elaberate on its use, but I'll bet this is it.
Larry Dighera
--
USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712
TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71)
UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp
UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!rootbreck@aimt.UU.NET (Robert Breckinridge Beatie) (02/16/89)
In article <502@maxim.ERBE.SE>, prc@maxim.ERBE.SE (Robert Claeson) writes: > In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. Camp) writes: > >My question is: What is the (historical or otherwise) justification for > >this rule? It seems wrong. I would have required write permission to > >the file itself in order that it be removed. ... > I think that what David meant is that it would make more sense to let > all objects in the file system have its own attributes, instead of > relying on the directory permissions for some things. And I agree -- > it certainly makes more sense to have a "delete" attribute on a file, > which must be set in order for me to remove it. And I'd like to add > an "append" attribute to the list. How would this "delete" attribute affect files with multiple links? No acceptable meaning springs directly to mind. It seems that there are two possibilities: 1) the "delete" attribute applies on every unlink operation. 2) the "delete" attribute applies only on the "last" unlink operation. Even if (2) is the accepted meaning, the "last" link to be severed may not be the original link to the file. So if I create a link in my home directory to a file owned by another uid, I might not be able to delete that link when I'm done with it. I'd have to ask the owner to delete a file in my directory. And perhaps I don't have "search" permissions turned on for that user in one or more of the link's parent directories. I suppose another possiblity would be to associate some more information with a link. Perhaps a count of the links that already connect to the file when the new link is created. Then the delete permission would apply only to the link whose "link-count" is zero. I suppose that would work, but it violates the principle that all links to a file are created equal. Besides, where would you put this extra information. (Of course this is not a problem for symbolic links.) The "append" attribute is interesting. But how often do you really want to allow a person to "append" to a file but not "write" to it. Or the opposite. Would you let the file owner specify "write" permission, but not "append"? And would that prohibit, not just opening for "append", but opening for "write" and then seeking to the end of file and writing? Or for that matter would it prohibit starting at the beginning of the file and then writing past the end of the file? As I said, I think the "append" attribute is an interesting idea. I'm just not sure how often I'd want to allow append permission and not write permission (or vice versa). As for the "delete" attribute, I really don't think it's a good idea. -- Breck Beatie (408)748-8649 {uunet,ames!coherent}!aimt!breck OR breck@aimt.uu.net "Sloppy as hell Little Father. You've embarassed me no end."
prc@maxim.ERBE.SE (Robert Claeson) (02/16/89)
In article <36398@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > In article <502@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: > >it certainly makes more sense to have a "delete" attribute on a file, > >which must be set in order for me to remove it. > But since Unix allows a single file to be accessed using multiple > directory entries, a single delete attribute isn't enough. How would > you specify that it is OK for anyone to remove some of the links, but > not others? > If you're going to allow multiple hard links, as Unix does, then it > doesn't make sense for deletability to be a file attribute, it must be > a link attribute. Yes, why not? I know it would break a lot of existing programs, as well as a re-design of the complete file system, but it's an interesting idea. . -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
jgy@opus.ATT.COM (John Young) (02/21/89)
In article <23095@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes: > In article <630@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: > <This is a future direction of UNIX question. > <I stumbled upon a system with /tmp directory permissions as follows: > < > < drwsrwxrwx ...... > < > <Note the "s". > <[...] namely a meaning for the set user id bit on directories. > <The meaning? Anyone could create files in the directory, > <but only the owner of the directory, OR the owner of the individual > <files could remove them. > <So, the questions: > < 1. Anyone know of the future fate of this useful tweak? > > At a presentation to the Orange County Unix Users Group last month the > AT&T speaker mentioned that Release 4 will support use of the suid bit > on directories. He didn't elaberate on its use, but I'll bet this is it. > > Larry Dighera Release 3.2 already supports this feature (only file owner & directory owner (and root)) may remove a file. This is implemented using the 't', sticky bit on the directory.
decot@hpisod2.HP.COM (Dave Decot) (02/21/89)
> In article <630@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: > <This is a future direction of UNIX question. > < > <I stumbled upon a system with /tmp directory permissions as follows: > < > < drwsrwxrwx ...... > < > <Note the "s". > <[...] namely a meaning for the set user id bit on directories. > <The meaning? Anyone could create files in the directory, > <but only the owner of the directory, OR the owner of the individual > <files could remove them. > <So, the questions: > < 1. Anyone know of the future fate of this useful tweak? > > At a presentation to the Orange County Unix Users Group last month the > AT&T speaker mentioned that Release 4 will support use of the suid bit > on directories. He didn't elaberate on its use, but I'll bet this is it. > > Larry Dighera SVID '89 says that the sticky bit is used for this purpose, not the setuid bit. It also says that this affects who can rename files in the directory in the same way. It does not mention any meaning for the setuid bit on directories. Dave
guy@auspex.UUCP (Guy Harris) (02/21/89)
>> At a presentation to the Orange County Unix Users Group last month the >> AT&T speaker mentioned that Release 4 will support use of the suid bit >> on directories. He didn't elaberate on its use, but I'll bet this is it. >> >Release 3.2 already supports this feature (only file owner & directory owner >(and root)) may remove a file. This is implemented using the 't', sticky >bit on the directory. Release 4.0 will, as far as I know, support use of the set-*group*id bit on directories, in the fashion of SunOS 4.0; if the directory has the set-gid bit set, files created in the directory get the group owner of the directory as their group owner, otherwise they get the effective GID of the creating process as the group owner. That accounts for the set-gid and sticky bits. Is there also going to be a meaning assigned to the set-*user*id bit as well, or did the AT&T speaker, or the person who was reporting it, mishear or misspeak?
frankb@usource.UUCP (Frank Bicknell) (02/22/89)
In article <85@opus.ATT.COM>, jgy@opus.ATT.COM (John Young) writes: > In article <23095@conexch.UUCP>, root@conexch.UUCP (Larry Dighera) writes: > > In article <630@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: > > <I stumbled upon a system with /tmp directory permissions as follows: > > < drwsrwxrwx ...... > > <Note the "s". > > <[...] namely a meaning for the set user id bit on directories. > > <Anyone could create files in the directory, > > <but only the owner of the directory, OR the owner of the individual > > <files could remove them. > > (note about the Orange County Unix Users Group omitted) > > Release 3.2 already supports this feature (only file owner & > directory owner (and root)) may remove a file. This is > implemented using the 't', sticky bit on the directory. I tried it on SCO Xenix 2.3.1... neither trick works :( . Sounds interesting, though! Why should this be implemented with the sticky bit, though? What does whether or not the directory's text image is saved after execution ( ;) ) have to do with permission to remove a file? Setuid bit seems to be the more logical choice. After all, you could extend this to the setgid bit, too, right? Then anyone in that group could also remove files. -- Frank Bicknell; 1405 Main St, Ste 709; Sarasota, FL 34236-5701 killer!usource!frankb
jhc@vax5.CIT.CORNELL.EDU (02/22/89)
In article <5714@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <1177@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes: >[the unix permissions scheme is intuitive because a directory >is a list of files] > >There is still a flaw. > >If a directory is like the card catalog in a library, and the files >themselves are like the books, then it is counter-intuitive that, when >somebody vandalizes the card catalog, all the books are destroyed too. > >In UNIX, the existence of a file under normal circumstances is nearly >synonymous with the existence of its directory entry. In a sense the >directory entry represents the file to the user, since he cannot look >at the file in any other way. It *is* counterintuitive that a >read-only file cannot be written to but can still be deleted. > >Thank heavens for the sticky bit on directories. It came just in time, >and does invalidate much of the criticism. It would seem to me, that if you make the analogy that Rahul makes, you need to go further and make the library one where the books are fetched for you by library staff, rather than one where the stacks have public access. Further, the gofers are somewhat dull, in that they can only find the books if someone tells them what the catalog numbers are--especially as (if this really _is_ the case) the books just might not have their catalog number written on themselves. Ie., PS344.A3S4 means something on the order of: go to floor PS, find room 344, go to stack row A, count up 3 shelves, find section S of said shelf, and choos the 4th slot.) Of course, the professional librarians can root thru the stacks and recatalog all of the books; this takes considerable time and is quite an annoyance--especially if somebody has a black-box that, when activated, will expand itself into a building exacltly like the library was at a certain point in time before the catalog was messed with. ;^) [By making the librarians capable of recataloging the files, I make the assumption that there exists somewhere a utility for UNIX that resembles the Mac's Fedit, or Norton for the PC's,...] Disclaimer: I'm makeing a couple of assumption on how the UNIX file system works, but I think that my assumptions are close to correct. (Although the 6+ step process of maping a US Lib. of Congress catalog number to a book was not supposed to indicate the there are that many steps involved in UNIX ;^) -JimC -- James H. Cloos, Jr. "Entropy isn't what it used to be." jhc@Crnlvax5.BITNET --c/o Fortune @ batcomputer.UUCP jhc@Vax5.CIT.Cornell.EDU #include <std_disclaimers.h> cornell!vax1!vax5.cit.cornell.edu!jhc@rochester.UUCP B-7 Upson Hall, Cornell Univ., Ithaca, NY 14853 +1 607 272 4519