All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subrata Modak <subrata@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: tolzmann@molgen.mpg.de, ltp-list@lists.sourceforge.net,
	bugzilla-daemon@bugzilla.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	bugme-daemon@bugzilla.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [LTP] [Bugme-new] [Bug 15909] New: open("a/", O_NOFOLLOW)	fails with ELOOP if "a" is a symbolic link to a directory.
Date: Tue, 11 May 2010 22:05:52 +0530	[thread overview]
Message-ID: <1273595753.4875.1.camel@subratamodak.linux.ibm.com> (raw)
In-Reply-To: <20100511162452.GD2832@quack.suse.cz>

Hi Jan,

On Tue, 2010-05-11 at 18:24 +0200, Jan Kara wrote:
> On Tue 11-05-10 17:48:51, Jan Kara wrote:
> > On Thu 06-05-10 14:30:02, Andrew Morton wrote:
> > > 
> > > (switched to email.  Please respond via emailed reply-to-all, not
> via the
> > > bugzilla web interface).
> > > 
> > > On Wed, 5 May 2010 13:01:22 GMT
> > > bugzilla-daemon@bugzilla.kernel.org wrote:
> > > 
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=15909
> > > > 
> > > >            Summary: open("a/",O_NOFOLLOW) fails with ELOOP if
> "a" is a
> > > >                     symbolic link to a directory.
> > > >            Product: File System
> > > >            Version: 2.5
> > > >     Kernel Version: 2.6.34-rc6
> > > >           Platform: All
> > > >         OS/Version: Linux
> > > >               Tree: Mainline
> > > >             Status: NEW
> > > >           Severity: high
> > > >           Priority: P1
> > > >          Component: Other
> > > >         AssignedTo: fs_other@kernel-bugs.osdl.org
> > > >         ReportedBy: tolzmann@molgen.mpg.de
> > > >         Regression: No
> > > > 
> > > > 
> > > > mkdir c
> > > > ln -s c a
> > > > 
> > > > f=open("a/",O_RDONLY+O_NOFOLLOW)
> > > > 
> > > > fails with ELOOP. However, this open should behave like
> open("a/.") not like
> > > > open("a") according to path_resolution(7). In kernel version
> 2.6.32 the open
> > > > worked as documented. 
> > > > 
> > > > On a higher level this bug makes
> > > > 
> > > > find a/
> > > > 
> > > > to fail.
> > > > 
> > > 
> > > It sounds like this 2.6.32->2.6.34-rc6 regression could have
> pretty
> > > serious ramifications for some users.  Does anyone know whcih
> commit
> > > might have caused it?
> >   The patch below fixes the issue for me but someone should have a
> look
> > at it because I'm not really an expert in that code and the code
> paths are so
> > twisted that my mind is currently tied into a knot ;).
> > 
> >                                                                       Honza
> > ---
> > 
> > From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00
> 2001
> > From: Jan Kara <jack@suse.cz>
> > Date: Tue, 11 May 2010 16:34:25 +0200
> > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with
> trailing slashes
> > 
> > According to specification
> > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY)
> > should return success but currently it did return ELOOP. Fix the
> code to ignore
> > O_NOFOLLOW in case the provided path has trailing slashes. This is a
> regression
> > caused by path lookup cleanup patch series.
> > 
> > CC: stable@kernel.org
> > Signed-off-by: Jan Kara <jack@suse.cz>
> ...
>   BTW: It might be worthwhile to add the attached testcase to LTP?

It would be great if you can shoot it in the form of a patch, mentioning

     1. The GPL Lincense,
     2. The purpose of the test case,
     3. Exact location it goes,
     4. Which LTPROOT/runtest/<file> executes it

Regards--
Subrata

:-)

> 
>                                                                         Honza
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
> 
> 
> 
> 
> 
> 
> 
> C++ source code
> attachment
> (open-follow-test.c)
> 
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <errno.h>
> #include <string.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> 
> int do_test(char *p)
> {
>   int err;
>   char path[16];
> 
>   strcpy(path, p);
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err >= 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) did not fail!
> \n", path);
>     return 1;
>   }
>   strcat(path, "/");
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err < 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with %
> d\n", path, errno);
>     return 1;
>   }
>   strcat(path, ".");
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err < 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with %
> d\n", path, errno);
>     return 1;
>   }
>   return 0;
> }
> 
> int main(void)
> {
>   if (mkdir("d", 0700) < 0) {
>     perror("mkdir");
>     return 1;
>   }
>   if (symlink("d", "a") < 0) {
>     perror("link");
>     return 1;
>   }
>   if (do_test("a"))
>     return 1;
>   return 0;
> }


------------------------------------------------------------------------------

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

WARNING: multiple messages have this Message-ID (diff)
From: Subrata Modak <subrata@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: ltp-list@lists.sourceforge.net, tolzmann@molgen.mpg.de,
	bugzilla-daemon@bugzilla.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	bugme-daemon@bugzilla.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [LTP] [Bugme-new] [Bug 15909] New: open("a/", O_NOFOLLOW) fails with ELOOP if "a" is a symbolic link to a directory.
Date: Tue, 11 May 2010 22:05:52 +0530	[thread overview]
Message-ID: <1273595753.4875.1.camel@subratamodak.linux.ibm.com> (raw)
In-Reply-To: <20100511162452.GD2832@quack.suse.cz>

Hi Jan,

On Tue, 2010-05-11 at 18:24 +0200, Jan Kara wrote:
> On Tue 11-05-10 17:48:51, Jan Kara wrote:
> > On Thu 06-05-10 14:30:02, Andrew Morton wrote:
> > > 
> > > (switched to email.  Please respond via emailed reply-to-all, not
> via the
> > > bugzilla web interface).
> > > 
> > > On Wed, 5 May 2010 13:01:22 GMT
> > > bugzilla-daemon@bugzilla.kernel.org wrote:
> > > 
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=15909
> > > > 
> > > >            Summary: open("a/",O_NOFOLLOW) fails with ELOOP if
> "a" is a
> > > >                     symbolic link to a directory.
> > > >            Product: File System
> > > >            Version: 2.5
> > > >     Kernel Version: 2.6.34-rc6
> > > >           Platform: All
> > > >         OS/Version: Linux
> > > >               Tree: Mainline
> > > >             Status: NEW
> > > >           Severity: high
> > > >           Priority: P1
> > > >          Component: Other
> > > >         AssignedTo: fs_other@kernel-bugs.osdl.org
> > > >         ReportedBy: tolzmann@molgen.mpg.de
> > > >         Regression: No
> > > > 
> > > > 
> > > > mkdir c
> > > > ln -s c a
> > > > 
> > > > f=open("a/",O_RDONLY+O_NOFOLLOW)
> > > > 
> > > > fails with ELOOP. However, this open should behave like
> open("a/.") not like
> > > > open("a") according to path_resolution(7). In kernel version
> 2.6.32 the open
> > > > worked as documented. 
> > > > 
> > > > On a higher level this bug makes
> > > > 
> > > > find a/
> > > > 
> > > > to fail.
> > > > 
> > > 
> > > It sounds like this 2.6.32->2.6.34-rc6 regression could have
> pretty
> > > serious ramifications for some users.  Does anyone know whcih
> commit
> > > might have caused it?
> >   The patch below fixes the issue for me but someone should have a
> look
> > at it because I'm not really an expert in that code and the code
> paths are so
> > twisted that my mind is currently tied into a knot ;).
> > 
> >                                                                       Honza
> > ---
> > 
> > From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00
> 2001
> > From: Jan Kara <jack@suse.cz>
> > Date: Tue, 11 May 2010 16:34:25 +0200
> > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with
> trailing slashes
> > 
> > According to specification
> > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY)
> > should return success but currently it did return ELOOP. Fix the
> code to ignore
> > O_NOFOLLOW in case the provided path has trailing slashes. This is a
> regression
> > caused by path lookup cleanup patch series.
> > 
> > CC: stable@kernel.org
> > Signed-off-by: Jan Kara <jack@suse.cz>
> ...
>   BTW: It might be worthwhile to add the attached testcase to LTP?

It would be great if you can shoot it in the form of a patch, mentioning

     1. The GPL Lincense,
     2. The purpose of the test case,
     3. Exact location it goes,
     4. Which LTPROOT/runtest/<file> executes it

Regards--
Subrata

:-)

> 
>                                                                         Honza
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
> 
> 
> 
> 
> 
> 
> 
> C++ source code
> attachment
> (open-follow-test.c)
> 
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <errno.h>
> #include <string.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> 
> int do_test(char *p)
> {
>   int err;
>   char path[16];
> 
>   strcpy(path, p);
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err >= 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) did not fail!
> \n", path);
>     return 1;
>   }
>   strcat(path, "/");
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err < 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with %
> d\n", path, errno);
>     return 1;
>   }
>   strcat(path, ".");
>   err = open(path, O_NOFOLLOW | O_RDONLY);
>   if (err < 0) {
>     fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with %
> d\n", path, errno);
>     return 1;
>   }
>   return 0;
> }
> 
> int main(void)
> {
>   if (mkdir("d", 0700) < 0) {
>     perror("mkdir");
>     return 1;
>   }
>   if (symlink("d", "a") < 0) {
>     perror("link");
>     return 1;
>   }
>   if (do_test("a"))
>     return 1;
>   return 0;
> }


  reply	other threads:[~2010-05-11 16:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-15909-10286@https.bugzilla.kernel.org/>
2010-05-06 21:30 ` [Bugme-new] [Bug 15909] New: open("a/", O_NOFOLLOW) fails with ELOOP if "a" is a symbolic link to a directory Andrew Morton
2010-05-09 15:29   ` OGAWA Hirofumi
2010-05-11 15:48   ` Jan Kara
2010-05-11 16:24     ` [LTP] " Jan Kara
2010-05-11 16:24       ` Jan Kara
2010-05-11 16:35       ` Subrata Modak [this message]
2010-05-11 16:35         ` [LTP] " Subrata Modak
2010-05-12 15:59         ` Jan Kara
2010-05-12 16:46           ` Subrata Modak
2010-05-13 11:29             ` Jan Kara
2010-05-17 20:06               ` Subrata Modak
2010-05-11 16:28     ` Jan Kara
2010-05-12 10:02       ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273595753.4875.1.camel@subratamodak.linux.ibm.com \
    --to=subrata@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=tolzmann@molgen.mpg.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.