Xy writes:
> (IMO) link should
> be modified because it does not make sense to allow users to create
> hard links to files they have no access to, in general. The mail
> spool example was simply one common example.
>
> IMO, if I have created a file, and I own the file, then there are only
> two users who should get to decide whether that file gets deleted or
> not: me, and root. Regular users should not be able to create hard
> links to my files, potentially without me knowing about it. Allowing
> them to do so means that you allow users who do not own a resource,
> and have no access to that resource, to potentially manage control of
> that resource to some extent. I don't see how this policy makes any
> sense. It allows that a file I created may be hanging around despite
> the fact that I think it's been deleted. And that just seems like a
> very bad idea to me.
It is a bad idea, especially since POSIX doesn't require it!
The 2001 UNIX/POSIX standard says:
The implementation may require that the calling
process has permission to access the existing file.
Then for error codes, EACCES means:
A component of either path prefix denies search
permission, or the requested link requires writing
in a directory that denies write permission, or
the calling process does not have permission to
access the existing file and this is required by
the implementation.
Maybe this should even apply to the owner.
("chmod 000 foo") Let's say that either
read or write permission is enough by default.
By mount option, both or neither may be required.
Pretty much any other restriction is OK as well,
due to the way the UNIX/POSIX standard uses the
term "access". For example:
An implementation may include other security
mechanisms in addition to those specified in
POSIX.1, and an access attempt may fail
because of those additional mechanisms, even
though it would succeed according to the
rules given in this section. (For example,
the user's security level might be lower than
that of the object of the access attempt.)
The standard defines an "additional file access
control mechanism" as pretty much any restriction
that one would care to add.
So restricting link() is 100% standards compliant.
How about: fail if (ctime^mtime+atime*owner)%3
:-)
-
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/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:25 EST