Messages in this thread |  | | Date | Sun, 15 Dec 1996 11:32:21 +1100 | From | Richard Gooch <> | Subject | Re: Proposal: restrict link(2) |
| |
Harald Koenig writes: > > > > why are you all advovating for a feature where noone could mention > > > any real use so far ? > > > > As I see it, it's _you_ who are advocating a new feature. Restricting the > > link system call would not change any rule, it would _add_ a new rule to > > how files are handled in Linux. Adding this new rule would complicate the > > file handling semantics in Linux. Furthermore, I do not think this new > > rule would fit in very well with the Unix file system astractions. > > still don't see that this would be a "new rule" or new feature. > IMHO it's a definition for a (yet) unspecified condition/operation.
I don't accept that this would not be a "new rule". How about if we changed the "cp" utility so that for every file copy it dumps a second copy somewhere in /tmp ? The current documentation doesn't say that it won't happen, so we can safely add this feature... It's not reducing functionality, it's *adding* it, right? Now, you want to *reduce* the functionality of link(2) (i.e not allow something that is currently allowed), and squirm and say since the current practice/documentation does not say that a non-owner is *allowed* to link(2), it's OK to add that restriction and pretend we haven't changed anything.
Adding this restriction belongs in a mount(8) option. It should not be forcibly enabled.
> I'm always asking *why* (for which reason, or maybe better which purpose) > something is done/allowed/not allowed/implemented/... > > for the question "why is a user allowed to create hard like to files of other users" > I haven't found any positive answer yet (please don't tell me > "that's UNIX fs semantics" again;) > > and I found/read no answer so far what we'd break if we would change > the behaviour of link(). I still think that it *absolute* no > real application will be affected...
Do you exclude users doing things on command lines from "application"? In any case, a legitimate use of link(2)ing to a file owned by someone else is the following:
A user has a large file on a shared data disc. That user lets other users know that this file will be available for the next few hours, and will then be deleted once the user has no futher need for the file. Other users link(2) the file (it's wasteful to copy that file many times, even one more copy is wasteful). They now know that they have access to the data for as long as they want, and the owner is free to remove (really, unlink(2)) it. Only one copy of the file is needed. When everyone decides that they have no more need for the file, it is deleted.
This is a big win in an environment where data are casually shared.
> Eric Troan wrote: > > : I couldn't find a POSIX verdict in ISO 9945-1. All it says is EPERM is > : returned it the user calling link() doesn't have "appropriate privileges" > : and that "appropriate privileges" are implementation defined. That doesn't > : seem to be much help. > > so at least for my understanding in this saying it would be perfect to say > that Linux doesn't allow to create hard linkes to files not owend and > thus return EPERM in this case because the user doesn't have "appropriate privileges" > (read: doesn't have ownership of the original file in this case).
Doing this without making it an option that the administrator can decide will mean that Linux will be viewed as having an unfavourable restriction by our user community. Making it a mount option allows the administrator to choose. I think such a mount option should exist, since restricting link(2) is really good idea for some sites. But please bear in mind that what is good for you is not necessarily good for others.
Regards,
Richard....
|  |