Messages in this thread | | | Date | Wed, 16 Jun 1999 23:49:16 +0200 | From | Wolfgang Walter <> | Subject | Re: [RFC] Bug in mkdir(2) |
| |
On Wed, Jun 16, 1999 at 04:59:10PM -0400, Douglas Weimer wrote: > Following symlinks can be useful at times. It is the root-owned > processes responsibility to check for symlinks in /tmp. This argument > can be used for any file manipulation in a globally writable directory. > Both mkdir("foo") and mkdir("foo/") should follow symlinks for > consistency purposes.
No. If there is no problem with important standards it should behave as kernel 2.0.x.
In general it is better not to follow dangling symlinks for actions which creates new fileystem entries. As symlinks and the referenced file is (in contrast to hardlinks) really something different, this makes much more sense.
Think of the situation:
touch a ln -s a b mkdir c rm a mkdir c
There is little reason why the second mkdir c should succeed, as the symlink really was a 'file'.
Following symlinks when creating filesystem objekts makes the secure cooperation of different unix-users much harder. If even rename would follow symlinks it would be impossible.
For example: Two collegues both work on a projekt. They share a common directory foo and a common group. Now person a does not believe that person b wants to do him something harmfull. On the other hand person a is not shure person b may not start a trojan horse, i.e.
So how they can cooperate? 2 possibilties: If mkdir (and rename) does not follow links:
mkdir b touch b/a rename b/a a
If only rename is save:
touch <really random number> rename <really random number> a
If even the rename system call follows symlinks it is rather impossible to share directories in a secure way.
The check for a symlink does not help as the operation is not atomic.
Wolfgang Walter
> > Doug > > > > > The same as for mkdir("foo")? mkdir behaves like open( ,O_CREAT|O_EXCL, ); > > Which doesn't follow links, by exactly the same reasons. Think of > > ln -sf <something_interesting_that_should_not_exist> /tmp/foo012345 > > when root-owned process is expected to create/mkdir/mknod/rename to > > /tmp/foo12345. > > > > Just to clarify: mkdir("foo") doesn't follow the link. mkdir("foo/") does. > > > > > > - > > 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/ > > > > > - > 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/
-- Veni, Vidi, VISA: I came, I saw, I did a little shopping.
- 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/
| |