Messages in this thread |  | | | From | (Peter Benie) | | Subject | Re: buglet in ext2 sticky bit? | | Date | Mon, 25 Oct 1999 17:19:59 +0100 |
| |
Frank van Maarseveen writes ("Re: buglet in ext2 sticky bit?"): > On Sun, Oct 24, 1999 at 10:06:15PM +0100, Matthew Kirkwood wrote: > > On Sun, 24 Oct 1999, Jan Kara wrote: > > > When it has sticky bit set than file can be deleted only by its owner > > > or owner of the directory. > > Intestingly, this works on Solaris 2.6 (both tmpfs and ufs). > > > > I seem to be able to delete any file in /tmp which I own _or_ can write > > to. > Oops, I remember something about ownership of symlinks. A symlink in /tmp > owned by root should never be unlinkable. Now we all know that the mode > of a symlink is meaningless so its owner must be meaningful in order to > create a difference in /tmp.
Solaris looks at the file permissions only, not the owner, to determine whether the filename can be deleted in a sticky directory. This is the case even for symlinks, so if you create a symlink in /tmp, then I, or any other user, can delete that symlink. This is not a feature that Linux should copy!
>For example, on OSF/1 4.x "tar x.." doesn't lchown() symlinks to the >original owner when invoked as root.
From the version number, I presume that's DEC OSF/1?
Some OSF/1 variants still don't have lchown. At least one variant allows you to chown symlinks if and only if they are dangling. Yuck.
> This dark corner in commercial UNIXes needs to be cleaned up but that's > not our task :-)
You won't get any argument from me there.
Personally I'd like the Linux sticky semantics to stay as they are. I think they give the user the least surprise. Programs that create world-writable lock files in /tmp are actually quite common, even on systems where anyone can delete such files; Linux gives the user some protection from broken programs that use these files.
Peter
- 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/
|  |