bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (12/16/85)
Here's one a faculty member pointed out, I suspect it was in relation to one of his courses: He makes a directory, call it 'gumby' and makes it 777 (world write is what's important here.) Someone else comes along and creates a directory 'gumby/pokey' (say protection 755) and puts a file (or more) into it, call it gumby/pokey/foo. At that point he can no longer remove the directory gumby because it is not empty. 'rm -r' et al don't help because the directory gumby/pokey is owned by the other user and does not allow him to delete the file gumby/pokey/foo, nor chmod it. I think he is stuck (obviously the student or myself can remove it.) If I recall correctly, what he does is create a subdir for his students. His students then create a subdir for themselves and put homeworks into it, so the way he got there is fairly reasonable (it is a high level, small course so security is not a big issue here I suspect, no need to belabor that.) Other than the obvious 'don't do it that way' am I missing something? Is this a bug? Anyone want to suggest a fix? -Barry Shein, Boston University P.S. If you think it's incredibly obvious you may have missed the point, try the following first from root: mkdir gumby chown yournonprivacct gumby chmod 777 gumby mkdir gumby/pokey chmod 755 gumby/pokey echo hello > gumby/pokey/foo Now make yourself non-prived (I just 'suspend' the 'su'd csh back to bzs) and try to remove everything. pokey and foo should be owned by root (or some other account.)
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/16/85)
The owner of the parent directory should be able to "mv" the subdirectory elsewhere (within the same file system) then "rm" his original directory. Presumably he would mail a note to the owner of the write-protected directory that he moved..
kre@munnari.OZ (Robert Elz) (12/17/85)
In article <729@brl-tgr.ARPA>, gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: > The owner of the parent directory should be able to "mv" > the subdirectory elsewhere ... I assume that Doug chose the words "should be able" very carefully. This cannot be done of course, as to move a directory, you have to change its back pointer (".."), and that involves writing in the (child) directory, which means that you have to have write permission in there... [Aside: I know that manipulating directories is a root only function, and root has permission to do anything, all that is irrelevant, the setuid programs that implement this, or the kernel sys calls that replaced them in 4.2, implement the same protection checks]. This is a logical outcome of the file system protection design, to change it would break some of the regularity of the whole thing. Whether that's important in this case is another matter entirely. This is also not a 4.2 "problem", this has existed in all of the research unix versions, since v5 at least. I have no idea what USG/USDL may have done in this area, but I suspect its probably the same in the Sys N releases too. Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/18/85)
> > The owner of the parent directory should be able to "mv" > > the subdirectory elsewhere ... > > I assume that Doug chose the words "should be able" very carefully. Actually, not as carefully as I should have. It would make sense for kernels (such as 4.2BSD) that have direct support for manipulating directories to provide a rename() system call that allows this, or for set-UID mv/mvdir utilities to allow this, but it doesn't surprise me that they don't.