[PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Ulrich Drepper]

When the linkat() syscall was added the flag parameter was added in the
last minute but it wasn't used so far.  The following patch should
change that.  My tests show that this is all that's needed.

If OLDNAME is a symlink setting the flag causes linkat to follow the
symlink and create a hardlink with the target.  This is actually
the behavior POSIX demands for link() as well but Linux wisely does
not do this.  With this flag (which will most likely be in the next
POSIX revision) the programmer can choose the behavior, defaulting
to the safe variant.  As a side effect it is now possible to implement
a POSIX-compliant link(2) function for those who are interested.

  touch file
  ln -s file symlink

  linkat(fd, "symlink", fd, "newlink", 0)
    -> newlink is hardlink of symlink

  linkat(fd, "symlink", fd, "newlink", AT_SYMLINK_FOLLOW)
    -> newlink is hardlink of file

The value of AT_SYMLINK_FOLLOW is determined by the definition we
already use in glibc.


Signed-Off-By: Ulrich Drepper <drepper@redhat.com>


 fs/namei.c            |    6 ++++--
 include/linux/fcntl.h |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)


--- linux/fs/namei.c-follow	2006-06-17 11:22:39.000000000 -0700
+++ linux/fs/namei.c	2006-06-17 11:58:18.000000000 -0700
@@ -2243,14 +2243,16 @@
 	int error;
 	char * to;
 
-	if (flags != 0)
+	if ((flags & ~AT_SYMLINK_FOLLOW) != 0)
 		return -EINVAL;
 
 	to = getname(newname);
 	if (IS_ERR(to))
 		return PTR_ERR(to);
 
-	error = __user_walk_fd(olddfd, oldname, 0, &old_nd);
+	error = __user_walk_fd(olddfd, oldname,
+			       flags & AT_SYMLINK_FOLLOW ? LOOKUP_FOLLOW : 0,
+			       &old_nd);
 	if (error)
 		goto exit;
 	error = do_path_lookup(newdfd, to, LOOKUP_PARENT, &nd);
--- linux/include/linux/fcntl.h-follow	2006-06-17 11:24:21.000000000 -0700
+++ linux/include/linux/fcntl.h	2006-06-17 11:24:51.000000000 -0700
@@ -29,6 +29,7 @@
 #define AT_SYMLINK_NOFOLLOW	0x100   /* Do not follow symbolic links.  */
 #define AT_REMOVEDIR		0x200   /* Remove directory instead of
                                            unlinking file.  */
+#define AT_SYMLINK_FOLLOW	0x400   /* Follow symbolic links.  */
 
 #ifdef __KERNEL__
 

Re: [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Al Viro]

On Sat, Jun 17, 2006 at 03:13:22PM -0400, Ulrich Drepper wrote:
> When the linkat() syscall was added the flag parameter was added in the
> last minute but it wasn't used so far.  The following patch should
> change that.  My tests show that this is all that's needed.
> 
> If OLDNAME is a symlink setting the flag causes linkat to follow the
> symlink and create a hardlink with the target.  This is actually
> the behavior POSIX demands for link() as well but Linux wisely does
> not do this.  With this flag (which will most likely be in the next
> POSIX revision) the programmer can choose the behavior, defaulting
> to the safe variant.  As a side effect it is now possible to implement
> a POSIX-compliant link(2) function for those who are interested.

Where does POSIX require that?  IIRC, it was along the lines of "application
can't rely on kernel doing the right thing", not "kernel must do the
wrong thing"...

Re: [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Linus Torvalds]

On Sun, 18 Jun 2006, Al Viro wrote:
> 
> Where does POSIX require that?  IIRC, it was along the lines of "application
> can't rely on kernel doing the right thing", not "kernel must do the
> wrong thing"...

Well, the patch as sent in does seem sane, as long as glibc doesn't start 
defaulting to the insane behaviour. Giving users the _ability_ to link to 
the symlink target is certainly not wrong, regardless of any standard. 
Doing it by default is another matter.

		Linus

Re: [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Al Viro]

On Sun, Jun 18, 2006 at 12:22:14PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 18 Jun 2006, Al Viro wrote:
> > 
> > Where does POSIX require that?  IIRC, it was along the lines of "application
> > can't rely on kernel doing the right thing", not "kernel must do the
> > wrong thing"...
> 
> Well, the patch as sent in does seem sane, as long as glibc doesn't start 
> defaulting to the insane behaviour. Giving users the _ability_ to link to 
> the symlink target is certainly not wrong, regardless of any standard. 
> Doing it by default is another matter.

As long as it doesn't get tied to overloaded environment variable that
might be needed for other purposes...

Re: [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Linus Torvalds wrote:
> Well, the patch as sent in does seem sane, as long as glibc doesn't start 
> defaulting to the insane behaviour. Giving users the _ability_ to link to 
> the symlink target is certainly not wrong, regardless of any standard. 
> Doing it by default is another matter.

I do not intend to change the link implementation in glibc.  That would
be majorly stupid, it'd break the ABI.

The AT_SYMLINK_FOLLOW flag to linkat was the result of the discussion
how to resolve the issue of the conflict between POSIX and the Linux
implementation of link (BTW: the Solaris link syscall behaves the same
as Linux's).  This is an easy an non-intrusive way to help people who
depend on the questionable POSIx-mandated behavior to work around the
incompatiblity.  Nothing more.  Don't change the link syscall, don't
assume the glibc will be changed.  This is only one little extra bit of
new functionality.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [PATCH] Implement AT_SYMLINK_FOLLOW flag for linkat

[Al Viro]

On Sun, Jun 18, 2006 at 12:40:43PM -0700, Ulrich Drepper wrote:
> Linus Torvalds wrote:
> > Well, the patch as sent in does seem sane, as long as glibc doesn't start 
> > defaulting to the insane behaviour. Giving users the _ability_ to link to 
> > the symlink target is certainly not wrong, regardless of any standard. 
> > Doing it by default is another matter.
> 
> I do not intend to change the link implementation in glibc.  That would
> be majorly stupid, it'd break the ABI.
> 
> The AT_SYMLINK_FOLLOW flag to linkat was the result of the discussion
> how to resolve the issue of the conflict between POSIX and the Linux
> implementation of link (BTW: the Solaris link syscall behaves the same
> as Linux's).

... while FreeBSD still doesn't have that 4.2BSD bug fixed, the suckers.

>   This is an easy an non-intrusive way to help people who
> depend on the questionable POSIx-mandated behavior to work around the
> incompatiblity.  Nothing more.  Don't change the link syscall, don't
> assume the glibc will be changed.  This is only one little extra bit of
> new functionality.

*shrug*

Fine by me; it's not really useful, but it's not a serious bloat either.

ACKed-by: Al Viro <viro@zeniv.linux.org.uk>