[lkml]   [1999]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Can't hardlink in different dirs. (BUG#826)

Thanks for your comments.

1. Coda's ctime not set on create is a bug -- I'll send a fix with the
other 2.3 fixes we will do over the next week or so.

2. Hard links across directories are not permitted. Jan explained that
security is an issue here.

I think there is wrong thinking in the way Unix does things normally and
the security argument goes away when the following reasoning is followed.

Unix pretends a hard link is merely a modification of a directory. Of
course it does add a name to new directory but it also subtly alters the
attributes of the file in question, since it raises the file's link count.

A perfectly acceptable fix for the (many) problems with link are to permit
links only if:

- the process can write to the target directory
- process can modify the attributes of the file it wants to link

This would work fine in Coda and also solves the problem that arise from
people keeping hardlinks to insecure suid programs, since they normally
cannot change their attributes.

Would Aegis be happy with that? Would Linux in general?

- Peter -

On Wed, 1 Dec 1999 wrote:

> On Wed, Dec 01, 1999 at 12:10:33PM -0500, wrote:
> > Full_Name: David Brown
> > Version: 5.3.1
> > OS: Linux
> > Submission from: (
> >
> > (Aegis again).
> >
> > Venus does not allow me to create hardlinks across directories. The following
> > in
> >
> > /* Don't allow hardlinks across different directories */
> > if (!parent_fso->dir_IsParent(&scp->c_fid)) {
> > /* Source exists, but it is not in the target parent. */
> > u.u_error = EXDEV;
> > goto FreeLocks;
> > }
> >
> > seems to indicate that this was intentionally forbidden. I'm assuming that
> > other things will break if links are created in differing directories.
> Yes, access is allowed/disallowed using ACLs on directories. Technically
> it is possible to create a hardlink to any file you can read. So if some
> user has more (or can gain more) permissions in the destination
> directory he suddenly can change the file.
> Another reason is that another directory could also be located in
> another volume, possibly on another server group. And then we would need
> to keep track of cross volume links.
> The important reason is the first. The -EXDEV is normal when people try
> to do things that cannot be done across mountpoints. (i.e. rename(2),
> link(2)) The fact that aegis doesn't handle this means that it also
> doesn't work on AFS, and on some installations with many physical
> disks or partitions such as a separate disk for source and objects.
> > How much work is it to make this work. This also prevents aegis from being
> > used, and I can't see as easy of a workaround for this.
> I don't know why aegis wants to create cross directory links. I read
> someplace that the maildir format recommends this trick as the only way
> to implement a reliable rename across directories on NFS filesystems. So
> if it is part of:
> link(dir1/file, dir2/file);
> unlink(dir1/file);
> You can safely replace it with:
> rename(dir1/file, dir2/file)
> Jan

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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