lkml.org 
[lkml]   [1996]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Proposal: restrict link(2)

Dan Merillat writes:
> Sheesh. I said link() modifies a file. And it _DOES_ It changes the file
> location, which _MAY_ change permissions of that file! (think of a group-only
> directory and someone in that group makes a link outside of it)
>
> It changes the lifespan of the file.
> It takes control of the file away from the owner, who can no longer delete
> the file.
> link() in a directory you own, mode 700. Now the owner _CANNOT_
> touch the file after they remove it! So yes, link() DOES modify a file
> and nobody can claim it does not!

link() modifies the inode (by changing the link count and possibly the
time stamps on the file) and it modifies a directory (by writing a new
entry into that directory). It does not modify the file data. The
linked file in a new directory may have different effective access
permissions because of the permissions on the directories above it, but
it still does not change the permissions of the file that was linked
to. Neither does it modify the file data.

There seems to be a lack of deep understanding about how link() works
and the relationships between directories, inodes, and file data,
because people either keep using inappropriate terminology or showing
substantial ignorance about what actually happens when links are created
and removed.

And, to bring this back on topic, the original proposal was to only
allow hard links to files that you have read access to. Unfortunately
that proposal won't affect any of the scenarios you mention in reference
to files that are readable by you.

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