Re: Proposal: restrict link(2)
Neil Moore (amethyst@valjean.sfhs.floyd.k12.ky.us)
Thu, 19 Dec 1996 08:33:10 -0500
>
>
> "A month of sundays ago Kevin M. Bealer wrote:"
> > Daniel Linder wrote:
> > >
> > [clip]
> > > I agree with Mr. VanDevender on this point. I personally have never
> > >used Quota on Linux so maybe this idea is off, but how about adding the
> > >smarts to the quota distribution? If this affects us, then it probably
> [clip]
> > How about this:
> >
> > Quota's can calculate usage by dividing the disk file by the
> > user count. A 500 MB file can be shared by 5 people who each
> > "pay" 100 MB.
>
> Well, my initial reaction was "No way!", because this means that
> you affect somebody else (the file owner) when you do something
> (hard link their file with a name in your space), but in fact all
> you can do is help them (by lowering their quota) so - maybe!
>
> But this is still unsatisfactory aesthetically. From the point of view
> of beauty and simplicity it seems to me that the owner of the original
> is the one and only with it on his quota. To continue ...
>
> Personally I would like to see the FS in general react by removing ALL
> links to a file when the _owner_ removes the file. OK - we get the same
> effect by letting the owner truncate the file before removing his link.
> The trouble is that it can't be the default for rm because that breaks all
> scripts that rely in the ln+rm trick to safely copy over files. Therefore
> it should be an option instead. Everybody immediately alias rm --for-real
> foo to "if #foo.links >1 then cp /dev/null foo fi; /bin/rm foo"
>
> The above stops other people file-stealing by waiting on your original
> to be erased.
Wouldn't having the FS remove a file on owner removal of a link
be a problem is you only *want* to remove one of the links?
Keep in mind the name and semantics of the syscall -- there is
a reason it is called unlink(2) and not delete(2). Also remember
that, with hard links, there is no single `real' dirent for the
file -- every link is just as real as every other. I do think
people who worry about quotas should do --truncate when rming
large files for now (if they use GNU rm).
Why not fix quota so that, if a file owned by user A is in a
directory owned by user B, for which user A does not have
execute access, user B gets charged? That file is doing user
A absolutely no good, as he cannot access it.
I also like the idea of storing a list of names/links in the
inode. Is there any reason not to do this? I don't know
much about the e2fs or VFS code, however, so I doubt I myself
will be writing a patch like this anytime soon.
Also, I think the original post in this thread (long, long,
ago, in a message, far, far, away) was about disallowing links
to non-owned files *when the new link would be in a sticky
directory* (like /tmp). Is there a problem with this? The
only one I can see is that it may cause lazy programmers to
rely on this feature, thus decreasing security for other systems
when linux programs written by lazy programmes are ported.
Any suggestions?
--
-Neil Moore http://www.sfhs.floyd.k12.ky.us/~amethyst
(finger amethyst@valjean.sfhs.floyd.k12.ky.us for my Geek Code)