opening symlinks with O_CREAT under latest 2.5.74

opening symlinks with O_CREAT under latest 2.5.74

[Petr Vandrovec]

Hi,
  couple of things stopped working on my box
where I have /dev/vc/XX as symlinks to /dev/ttyXX, and some
things use /dev/vc/XX and some /dev/ttyXX. After last update
hour ago things which use /dev/vc/XX stopped working for
non-root - they now fail with EACCES error if they attempt
to redirect its input or output through '>' or '<>' bash
redirection operators:

$ touch /tmp/xx
$ ln -s /tmp/xx yy
$ cat > yy
-bash: yy: Permission denied

Strace says:

[pid  3268] open("yy", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)

This command succeeds on kernel from thursday. Simillar problem is
that

$ rm /tmp/xx
$ ln -s /tmp/xx yy
$ cat > yy
-bash: yy: No such file or directory

while it creates /tmp/xx file on older kernels.

  Currently I suspect Trond's LOOKUP_CONTINUE change in 
'[PATCH] Add open intent information to the 'struct nameidata', but I
did not tried reverting it yet to find whether it is culprit or no. But
other changes than these four from Trond looks completely innocent.
					Thanks,
						Petr Vandrovec
						vandrove@vc.cvut.cz

Re: opening symlinks with O_CREAT under latest 2.5.74

[Felipe Alfaro Solana]

On Mon, 2003-07-07 at 17:46, Petr Vandrovec wrote:
> Hi,
>   couple of things stopped working on my box
> where I have /dev/vc/XX as symlinks to /dev/ttyXX, and some
> things use /dev/vc/XX and some /dev/ttyXX. After last update
> hour ago things which use /dev/vc/XX stopped working for
> non-root - they now fail with EACCES error if they attempt
> to redirect its input or output through '>' or '<>' bash
> redirection operators:
> 
> $ touch /tmp/xx
> $ ln -s /tmp/xx yy
> $ cat > yy
> -bash: yy: Permission denied
> 
> Strace says:
> 
> [pid  3268] open("yy", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)
> 
> This command succeeds on kernel from thursday. Simillar problem is
> that
> 
> $ rm /tmp/xx
> $ ln -s /tmp/xx yy
> $ cat > yy
> -bash: yy: No such file or directory
> 
> while it creates /tmp/xx file on older kernels.
> 
>   Currently I suspect Trond's LOOKUP_CONTINUE change in 
> '[PATCH] Add open intent information to the 'struct nameidata', but I
> did not tried reverting it yet to find whether it is culprit or no. But
> other changes than these four from Trond looks completely innocent.

JFYI, on Red Hat 9, I'm having problems when using "vi" to edit a file
through a symbolic link. For example, I can't save changes with ":wq!"
in vi when editing "/etc/grub.conf" on my RHL9 box (which is a symbolic
link to "/boot/grub/grub.conf").

Re: opening symlinks with O_CREAT under latest 2.5.74

[Petr Vandrovec]

On Mon, Jul 07, 2003 at 08:49:29PM +0200, Felipe Alfaro Solana wrote:
> On Mon, 2003-07-07 at 17:46, Petr Vandrovec wrote:
> > Hi,
> >   couple of things stopped working on my box
> > where I have /dev/vc/XX as symlinks to /dev/ttyXX, and some
> > things use /dev/vc/XX and some /dev/ttyXX. After last update
> > hour ago things which use /dev/vc/XX stopped working for
> > non-root - they now fail with EACCES error if they attempt
> > to redirect its input or output through '>' or '<>' bash
> > redirection operators:
> > 
> > $ touch /tmp/xx
> > $ ln -s /tmp/xx yy
> > $ cat > yy
> > -bash: yy: Permission denied
> > 
> > Strace says:
> > 
> > [pid  3268] open("yy", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)

> >   Currently I suspect Trond's LOOKUP_CONTINUE change in 
> > '[PATCH] Add open intent information to the 'struct nameidata', but I
> > did not tried reverting it yet to find whether it is culprit or no. But
> > other changes than these four from Trond looks completely innocent.

Reverting "trond.myklebust@fys.uio.no|ChangeSet|20030704190606|14242" indeed
fixes problem.

> JFYI, on Red Hat 9, I'm having problems when using "vi" to edit a file
> through a symbolic link. For example, I can't save changes with ":wq!"
> in vi when editing "/etc/grub.conf" on my RHL9 box (which is a symbolic
> link to "/boot/grub/grub.conf").

I think that it is unrelated.
						Petr Vandrovec
						vandrove@vc.cvut.cz

opening symlinks with O_CREAT under latest 2.5.74

[Trond Myklebust]

>>>>> " " == Petr Vandrovec <vandrove@vc.cvut.cz> writes:

     > Hi,
     >   couple of things stopped working on my box
     > where I have /dev/vc/XX as symlinks to /dev/ttyXX, and some
     > things use /dev/vc/XX and some /dev/ttyXX. After last update
     > hour ago things which use /dev/vc/XX stopped working for
     > non-root - they now fail with EACCES error if they attempt to
     > redirect its input or output through '>' or '<>' bash
     > redirection operators:

Whoops. Looks like I missed an assumption in open_namei().
Does the following patch fix the problem?

Cheers,
  Trond

--- linux-2.5.74-up/fs/namei.c.orig	2003-06-30 08:49:25.000000000 +0200
+++ linux-2.5.74-up/fs/namei.c	2003-07-07 21:25:00.000000000 +0200
@@ -1344,6 +1344,7 @@
 	 * stored in nd->last.name and we will have to putname() it when we
 	 * are done. Procfs-like symlinks just set LAST_BIND.
 	 */
+	nd->flags |= LOOKUP_PARENT;
 	error = security_inode_follow_link(dentry, nd);
 	if (error)
 		goto exit_dput;
@@ -1352,6 +1353,7 @@
 	dput(dentry);
 	if (error)
 		return error;
+	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND) {
 		dentry = nd->dentry;
 		goto ok;

Re: opening symlinks with O_CREAT under latest 2.5.74

[Petr Vandrovec]

On Mon, Jul 07, 2003 at 09:30:34PM +0200, Trond Myklebust wrote:
> >>>>> " " == Petr Vandrovec <vandrove@vc.cvut.cz> writes:
> 
>      > Hi,
>      >   couple of things stopped working on my box
>      > where I have /dev/vc/XX as symlinks to /dev/ttyXX, and some
>      > things use /dev/vc/XX and some /dev/ttyXX. After last update
>      > hour ago things which use /dev/vc/XX stopped working for
>      > non-root - they now fail with EACCES error if they attempt to
>      > redirect its input or output through '>' or '<>' bash
>      > redirection operators:
> 
> Whoops. Looks like I missed an assumption in open_namei().
> Does the following patch fix the problem?

Yes, it fixes problem. Thanks,
						Petr Vandrovec

> Cheers,
>   Trond
> 
> --- linux-2.5.74-up/fs/namei.c.orig	2003-06-30 08:49:25.000000000 +0200
> +++ linux-2.5.74-up/fs/namei.c	2003-07-07 21:25:00.000000000 +0200
> @@ -1344,6 +1344,7 @@
>  	 * stored in nd->last.name and we will have to putname() it when we
>  	 * are done. Procfs-like symlinks just set LAST_BIND.
>  	 */
> +	nd->flags |= LOOKUP_PARENT;
>  	error = security_inode_follow_link(dentry, nd);
>  	if (error)
>  		goto exit_dput;
> @@ -1352,6 +1353,7 @@
>  	dput(dentry);
>  	if (error)
>  		return error;
> +	nd->flags &= ~LOOKUP_PARENT;
>  	if (nd->last_type == LAST_BIND) {
>  		dentry = nd->dentry;
>  		goto ok;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: opening symlinks with O_CREAT under latest 2.5.74

[Andrew Morton]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> Whoops. Looks like I missed an assumption in open_namei().
> Does the following patch fix the problem?

Yes.