[lkml]   [1996]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Proposal: restrict link(2)

    > "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
    (finger for my Geek Code)

     \ /
      Last update: 2005-03-22 13:38    [W:0.020 / U:302.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site