lkml.org 
[lkml]   [1996]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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....

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.097 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site