You can't tell who the user is. ANY user would be able to do that.
> > > I do not even see a security hole if nobody other than the user itself
> > > and httpd/web can reach this area in the file system, anyway. And it
> > > is still the users decision that files in this (his) directory should
> > > belong to him.
> >
> > 1. users will steal/bypass quota controls
>
> Not in my example - acutally even the other way around.
And just how is it prevented? quotas are applied based on either group
or user. Normally it is based on user. Once the uid is set, then the
quotas start being deducted. If the the user procedes to store 10 G of
music files, who is charged? And how do you know who put them there.
> > 2. Consider what happens if a user creates a file in such a directory
> > and it is executable. - since the file is fully owned by a different
> > user, it appears to have been created by that user. What protection
> > mask is on the file? Can the creator (not owner) make it setuid?
> > (nasty worm propagation method)
>
> Again: it depends on the usage. In my case it is the other way around. A
> use should know what he is doing if he is setting this flag on a
> directory. And making such files suid again, has to be prevented by the
> code - that I even mentioned in my first mail on this issue.
How are you going to control it?
> > > Actually, the suid bit on directories works at least under FreeBSD. Is
> > > there any reason, why it does not work under Linux?
> >
> > I don't believe it is in the POSIX definition.
>
> I only said, it works under FreeBSD, it is an option there.
Then use FreeBSD.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/