Mount failure due to restricted access to a point along the mount path

Mount failure due to restricted access to a point along the mount path

[Miklos Szeredi]

Hi,

A while ago this was discussed:

  http://thread.gmane.org/gmane.linux.kernel.cifs/7779

This is essentially a regression introduced by the shared superblock
changes in 3.0 and several SUSE customers are complaining about it.
I've created a temporary fix which reverts 29 commits related to the
shared superblock changes.  It works, but it's obviously not a
permanent fix, especially since we definitely don't want to diverge
from mainline.

Is this issue being worked on?  Don't other distros have similar reports?

Thanks,
Miklos

Re: Mount failure due to restricted access to a point along the mount path

[Jeff Layton]

On Fri, 10 May 2013 16:13:30 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:

> Hi,
> 
> A while ago this was discussed:
> 
>   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
> 
> This is essentially a regression introduced by the shared superblock
> changes in 3.0 and several SUSE customers are complaining about it.
> I've created a temporary fix which reverts 29 commits related to the
> shared superblock changes.  It works, but it's obviously not a
> permanent fix, especially since we definitely don't want to diverge
> from mainline.
> 
> Is this issue being worked on?  Don't other distros have similar reports?
> 
> Thanks,
> Miklos

I don't know of anyone currently working on it. There are a couple of
possible approaches to fixing it, I think:

1) if the dentries to get down to the root of the mount don't already
exist, then attach some sort of "placeholder" inode that can be fleshed
out later if and when the dentry is accessed via other means.

2) do something like what NFS does (see commit 54ceac45). This becomes
a bit more complicated due to the fact that the server may not hand out
real inode numbers and we sometimes have to fake them up.

#1 is probably simpler to implement, but I'll confess that I haven't
thought through all of the potential problems with it.

-- 
Jeff Layton <jlayton@redhat.com>

Re: Mount failure due to restricted access to a point along the mount path

[Jeff Layton]

On Fri, 10 May 2013 10:27:54 -0400
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> On Fri, 10 May 2013 16:13:30 +0200
> Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> wrote:
> 
> > Hi,
> > 
> > A while ago this was discussed:
> > 
> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
> > 
> > This is essentially a regression introduced by the shared superblock
> > changes in 3.0 and several SUSE customers are complaining about it.
> > I've created a temporary fix which reverts 29 commits related to the
> > shared superblock changes.  It works, but it's obviously not a
> > permanent fix, especially since we definitely don't want to diverge
> > from mainline.
> > 
> > Is this issue being worked on?  Don't other distros have similar reports?
> > 
> > Thanks,
> > Miklos
> 
> I don't know of anyone currently working on it. There are a couple of
> possible approaches to fixing it, I think:
> 
> 1) if the dentries to get down to the root of the mount don't already
> exist, then attach some sort of "placeholder" inode that can be fleshed
> out later if and when the dentry is accessed via other means.
> 
> 2) do something like what NFS does (see commit 54ceac45). This becomes
> a bit more complicated due to the fact that the server may not hand out
> real inode numbers and we sometimes have to fake them up.
> 
> #1 is probably simpler to implement, but I'll confess that I haven't
> thought through all of the potential problems with it.
> 

So, giving this some more thought, I think #2 is really the correct way
to fix this. Here's the main problem though:

Suppose someone mounts:

    //server/share/foo/bar/baz

We make the sb->s_root point to the top level share, and then create a
disconnected dentry for "baz" to return from ->mount.

Then, a little while later, //server/share gets mounted separately and
a user walks down to /foo/bar/baz within the same share.

How do we ensure that we don't end up with two "baz" dentries in this
situation? With NFS, we can be reasonably sure that there's a 1:1
correspondance of filehandle to inode.

Under CIFS, it's possible that it's faking up inode numbers if the
server doesn't provide them via a UniqueID field. The only real
identifying info we have for the inode in that case is the pathname.

Perhaps we'd be best off to just rip out the sb sharing after all.
Getting all of the corner cases right when the protocol and server
implementations are so problematic is really, really difficult.

If we do go that route, then the fscache code will need some work since
it uses the sharename as a sb cookie.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: Mount failure due to restricted access to a point along the mount path

[Jeff Layton]

On Fri, 10 May 2013 10:27:54 -0400
Jeff Layton <jlayton@redhat.com> wrote:

> On Fri, 10 May 2013 16:13:30 +0200
> Miklos Szeredi <miklos@szeredi.hu> wrote:
> 
> > Hi,
> > 
> > A while ago this was discussed:
> > 
> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
> > 
> > This is essentially a regression introduced by the shared superblock
> > changes in 3.0 and several SUSE customers are complaining about it.
> > I've created a temporary fix which reverts 29 commits related to the
> > shared superblock changes.  It works, but it's obviously not a
> > permanent fix, especially since we definitely don't want to diverge
> > from mainline.
> > 
> > Is this issue being worked on?  Don't other distros have similar reports?
> > 
> > Thanks,
> > Miklos
> 
> I don't know of anyone currently working on it. There are a couple of
> possible approaches to fixing it, I think:
> 
> 1) if the dentries to get down to the root of the mount don't already
> exist, then attach some sort of "placeholder" inode that can be fleshed
> out later if and when the dentry is accessed via other means.
> 
> 2) do something like what NFS does (see commit 54ceac45). This becomes
> a bit more complicated due to the fact that the server may not hand out
> real inode numbers and we sometimes have to fake them up.
> 
> #1 is probably simpler to implement, but I'll confess that I haven't
> thought through all of the potential problems with it.
> 

So, giving this some more thought, I think #2 is really the correct way
to fix this. Here's the main problem though:

Suppose someone mounts:

    //server/share/foo/bar/baz

We make the sb->s_root point to the top level share, and then create a
disconnected dentry for "baz" to return from ->mount.

Then, a little while later, //server/share gets mounted separately and
a user walks down to /foo/bar/baz within the same share.

How do we ensure that we don't end up with two "baz" dentries in this
situation? With NFS, we can be reasonably sure that there's a 1:1
correspondance of filehandle to inode.

Under CIFS, it's possible that it's faking up inode numbers if the
server doesn't provide them via a UniqueID field. The only real
identifying info we have for the inode in that case is the pathname.

Perhaps we'd be best off to just rip out the sb sharing after all.
Getting all of the corner cases right when the protocol and server
implementations are so problematic is really, really difficult.

If we do go that route, then the fscache code will need some work since
it uses the sharename as a sb cookie.

-- 
Jeff Layton <jlayton@redhat.com>

Re: Mount failure due to restricted access to a point along the mount path

[Steve French]

On Tue, May 14, 2013 at 3:51 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 10 May 2013 10:27:54 -0400
> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> On Fri, 10 May 2013 16:13:30 +0200
>> Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> wrote:
>>
>> > Hi,
>> >
>> > A while ago this was discussed:
>> >
>> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >
>> > This is essentially a regression introduced by the shared superblock
>> > changes in 3.0 and several SUSE customers are complaining about it.
>> > I've created a temporary fix which reverts 29 commits related to the
>> > shared superblock changes.  It works, but it's obviously not a
>> > permanent fix, especially since we definitely don't want to diverge
>> > from mainline.
>> >
>> > Is this issue being worked on?  Don't other distros have similar reports?
>> >
>> > Thanks,
>> > Miklos
>>
>> I don't know of anyone currently working on it. There are a couple of
>> possible approaches to fixing it, I think:
>>
>> 1) if the dentries to get down to the root of the mount don't already
>> exist, then attach some sort of "placeholder" inode that can be fleshed
>> out later if and when the dentry is accessed via other means.
>>
>> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> a bit more complicated due to the fact that the server may not hand out
>> real inode numbers and we sometimes have to fake them up.
>>
>> #1 is probably simpler to implement, but I'll confess that I haven't
>> thought through all of the potential problems with it.
>>
>
> So, giving this some more thought, I think #2 is really the correct way
> to fix this. Here's the main problem though:
>
> Suppose someone mounts:
>
>     //server/share/foo/bar/baz
>
> We make the sb->s_root point to the top level share, and then create a
> disconnected dentry for "baz" to return from ->mount.
>
> Then, a little while later, //server/share gets mounted separately and
> a user walks down to /foo/bar/baz within the same share.
>
> How do we ensure that we don't end up with two "baz" dentries in this
> situation? With NFS, we can be reasonably sure that there's a 1:1
> correspondance of filehandle to inode.
>
> Under CIFS, it's possible that it's faking up inode numbers if the
> server doesn't provide them via a UniqueID field. The only real
> identifying info we have for the inode in that case is the pathname.

Since this (support for server generated inode numbers) is most common
case (especially with SMB2 and later) - I don't mind making dependency
on the server supporting UniqueID for this.
-- 
Thanks,

Steve

Re: Mount failure due to restricted access to a point along the mount path

[Steve French]

On Tue, May 14, 2013 at 3:51 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 10 May 2013 10:27:54 -0400
> Jeff Layton <jlayton@redhat.com> wrote:
>
>> On Fri, 10 May 2013 16:13:30 +0200
>> Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> > Hi,
>> >
>> > A while ago this was discussed:
>> >
>> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >
>> > This is essentially a regression introduced by the shared superblock
>> > changes in 3.0 and several SUSE customers are complaining about it.
>> > I've created a temporary fix which reverts 29 commits related to the
>> > shared superblock changes.  It works, but it's obviously not a
>> > permanent fix, especially since we definitely don't want to diverge
>> > from mainline.
>> >
>> > Is this issue being worked on?  Don't other distros have similar reports?
>> >
>> > Thanks,
>> > Miklos
>>
>> I don't know of anyone currently working on it. There are a couple of
>> possible approaches to fixing it, I think:
>>
>> 1) if the dentries to get down to the root of the mount don't already
>> exist, then attach some sort of "placeholder" inode that can be fleshed
>> out later if and when the dentry is accessed via other means.
>>
>> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> a bit more complicated due to the fact that the server may not hand out
>> real inode numbers and we sometimes have to fake them up.
>>
>> #1 is probably simpler to implement, but I'll confess that I haven't
>> thought through all of the potential problems with it.
>>
>
> So, giving this some more thought, I think #2 is really the correct way
> to fix this. Here's the main problem though:
>
> Suppose someone mounts:
>
>     //server/share/foo/bar/baz
>
> We make the sb->s_root point to the top level share, and then create a
> disconnected dentry for "baz" to return from ->mount.
>
> Then, a little while later, //server/share gets mounted separately and
> a user walks down to /foo/bar/baz within the same share.
>
> How do we ensure that we don't end up with two "baz" dentries in this
> situation? With NFS, we can be reasonably sure that there's a 1:1
> correspondance of filehandle to inode.
>
> Under CIFS, it's possible that it's faking up inode numbers if the
> server doesn't provide them via a UniqueID field. The only real
> identifying info we have for the inode in that case is the pathname.

Since this (support for server generated inode numbers) is most common
case (especially with SMB2 and later) - I don't mind making dependency
on the server supporting UniqueID for this.
-- 
Thanks,

Steve

Re: Mount failure due to restricted access to a point along the mount path

[Jeff Layton]

On Tue, 14 May 2013 05:44:48 -0500
Steve French <smfrench@gmail.com> wrote:

> On Tue, May 14, 2013 at 3:51 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > On Fri, 10 May 2013 10:27:54 -0400
> > Jeff Layton <jlayton@redhat.com> wrote:
> >
> >> On Fri, 10 May 2013 16:13:30 +0200
> >> Miklos Szeredi <miklos@szeredi.hu> wrote:
> >>
> >> > Hi,
> >> >
> >> > A while ago this was discussed:
> >> >
> >> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
> >> >
> >> > This is essentially a regression introduced by the shared superblock
> >> > changes in 3.0 and several SUSE customers are complaining about it.
> >> > I've created a temporary fix which reverts 29 commits related to the
> >> > shared superblock changes.  It works, but it's obviously not a
> >> > permanent fix, especially since we definitely don't want to diverge
> >> > from mainline.
> >> >
> >> > Is this issue being worked on?  Don't other distros have similar reports?
> >> >
> >> > Thanks,
> >> > Miklos
> >>
> >> I don't know of anyone currently working on it. There are a couple of
> >> possible approaches to fixing it, I think:
> >>
> >> 1) if the dentries to get down to the root of the mount don't already
> >> exist, then attach some sort of "placeholder" inode that can be fleshed
> >> out later if and when the dentry is accessed via other means.
> >>
> >> 2) do something like what NFS does (see commit 54ceac45). This becomes
> >> a bit more complicated due to the fact that the server may not hand out
> >> real inode numbers and we sometimes have to fake them up.
> >>
> >> #1 is probably simpler to implement, but I'll confess that I haven't
> >> thought through all of the potential problems with it.
> >>
> >
> > So, giving this some more thought, I think #2 is really the correct way
> > to fix this. Here's the main problem though:
> >
> > Suppose someone mounts:
> >
> >     //server/share/foo/bar/baz
> >
> > We make the sb->s_root point to the top level share, and then create a
> > disconnected dentry for "baz" to return from ->mount.
> >
> > Then, a little while later, //server/share gets mounted separately and
> > a user walks down to /foo/bar/baz within the same share.
> >
> > How do we ensure that we don't end up with two "baz" dentries in this
> > situation? With NFS, we can be reasonably sure that there's a 1:1
> > correspondance of filehandle to inode.
> >
> > Under CIFS, it's possible that it's faking up inode numbers if the
> > server doesn't provide them via a UniqueID field. The only real
> > identifying info we have for the inode in that case is the pathname.
> 
> Since this (support for server generated inode numbers) is most common
> case (especially with SMB2 and later) - I don't mind making dependency
> on the server supporting UniqueID for this.

There are still some problems even when the server does supply them. We
sometimes find that they aren't suitable for various reasons or aren't
to be trusted, and the client disables server inode numbers on the fly.

What do you do at that point if you already have 2 mounts sharing the
superblock?

-- 
Jeff Layton <jlayton@redhat.com>

Re: Mount failure due to restricted access to a point along the mount path

[Steve French]

Well at least for SMB2 we know they should be ok

On Tue, May 14, 2013 at 6:09 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 14 May 2013 05:44:48 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Tue, May 14, 2013 at 3:51 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Fri, 10 May 2013 10:27:54 -0400
>> > Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> >
>> >> On Fri, 10 May 2013 16:13:30 +0200
>> >> Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > A while ago this was discussed:
>> >> >
>> >> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >> >
>> >> > This is essentially a regression introduced by the shared superblock
>> >> > changes in 3.0 and several SUSE customers are complaining about it.
>> >> > I've created a temporary fix which reverts 29 commits related to the
>> >> > shared superblock changes.  It works, but it's obviously not a
>> >> > permanent fix, especially since we definitely don't want to diverge
>> >> > from mainline.
>> >> >
>> >> > Is this issue being worked on?  Don't other distros have similar reports?
>> >> >
>> >> > Thanks,
>> >> > Miklos
>> >>
>> >> I don't know of anyone currently working on it. There are a couple of
>> >> possible approaches to fixing it, I think:
>> >>
>> >> 1) if the dentries to get down to the root of the mount don't already
>> >> exist, then attach some sort of "placeholder" inode that can be fleshed
>> >> out later if and when the dentry is accessed via other means.
>> >>
>> >> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> >> a bit more complicated due to the fact that the server may not hand out
>> >> real inode numbers and we sometimes have to fake them up.
>> >>
>> >> #1 is probably simpler to implement, but I'll confess that I haven't
>> >> thought through all of the potential problems with it.
>> >>
>> >
>> > So, giving this some more thought, I think #2 is really the correct way
>> > to fix this. Here's the main problem though:
>> >
>> > Suppose someone mounts:
>> >
>> >     //server/share/foo/bar/baz
>> >
>> > We make the sb->s_root point to the top level share, and then create a
>> > disconnected dentry for "baz" to return from ->mount.
>> >
>> > Then, a little while later, //server/share gets mounted separately and
>> > a user walks down to /foo/bar/baz within the same share.
>> >
>> > How do we ensure that we don't end up with two "baz" dentries in this
>> > situation? With NFS, we can be reasonably sure that there's a 1:1
>> > correspondance of filehandle to inode.
>> >
>> > Under CIFS, it's possible that it's faking up inode numbers if the
>> > server doesn't provide them via a UniqueID field. The only real
>> > identifying info we have for the inode in that case is the pathname.
>>
>> Since this (support for server generated inode numbers) is most common
>> case (especially with SMB2 and later) - I don't mind making dependency
>> on the server supporting UniqueID for this.
>
> There are still some problems even when the server does supply them. We
> sometimes find that they aren't suitable for various reasons or aren't
> to be trusted, and the client disables server inode numbers on the fly.
>
> What do you do at that point if you already have 2 mounts sharing the
> superblock?
>
> --
> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>



-- 
Thanks,

Steve

Re: Mount failure due to restricted access to a point along the mount path

[Steve French]

Well at least for SMB2 we know they should be ok

On Tue, May 14, 2013 at 6:09 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Tue, 14 May 2013 05:44:48 -0500
> Steve French <smfrench@gmail.com> wrote:
>
>> On Tue, May 14, 2013 at 3:51 AM, Jeff Layton <jlayton@redhat.com> wrote:
>> > On Fri, 10 May 2013 10:27:54 -0400
>> > Jeff Layton <jlayton@redhat.com> wrote:
>> >
>> >> On Fri, 10 May 2013 16:13:30 +0200
>> >> Miklos Szeredi <miklos@szeredi.hu> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > A while ago this was discussed:
>> >> >
>> >> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >> >
>> >> > This is essentially a regression introduced by the shared superblock
>> >> > changes in 3.0 and several SUSE customers are complaining about it.
>> >> > I've created a temporary fix which reverts 29 commits related to the
>> >> > shared superblock changes.  It works, but it's obviously not a
>> >> > permanent fix, especially since we definitely don't want to diverge
>> >> > from mainline.
>> >> >
>> >> > Is this issue being worked on?  Don't other distros have similar reports?
>> >> >
>> >> > Thanks,
>> >> > Miklos
>> >>
>> >> I don't know of anyone currently working on it. There are a couple of
>> >> possible approaches to fixing it, I think:
>> >>
>> >> 1) if the dentries to get down to the root of the mount don't already
>> >> exist, then attach some sort of "placeholder" inode that can be fleshed
>> >> out later if and when the dentry is accessed via other means.
>> >>
>> >> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> >> a bit more complicated due to the fact that the server may not hand out
>> >> real inode numbers and we sometimes have to fake them up.
>> >>
>> >> #1 is probably simpler to implement, but I'll confess that I haven't
>> >> thought through all of the potential problems with it.
>> >>
>> >
>> > So, giving this some more thought, I think #2 is really the correct way
>> > to fix this. Here's the main problem though:
>> >
>> > Suppose someone mounts:
>> >
>> >     //server/share/foo/bar/baz
>> >
>> > We make the sb->s_root point to the top level share, and then create a
>> > disconnected dentry for "baz" to return from ->mount.
>> >
>> > Then, a little while later, //server/share gets mounted separately and
>> > a user walks down to /foo/bar/baz within the same share.
>> >
>> > How do we ensure that we don't end up with two "baz" dentries in this
>> > situation? With NFS, we can be reasonably sure that there's a 1:1
>> > correspondance of filehandle to inode.
>> >
>> > Under CIFS, it's possible that it's faking up inode numbers if the
>> > server doesn't provide them via a UniqueID field. The only real
>> > identifying info we have for the inode in that case is the pathname.
>>
>> Since this (support for server generated inode numbers) is most common
>> case (especially with SMB2 and later) - I don't mind making dependency
>> on the server supporting UniqueID for this.
>
> There are still some problems even when the server does supply them. We
> sometimes find that they aren't suitable for various reasons or aren't
> to be trusted, and the client disables server inode numbers on the fly.
>
> What do you do at that point if you already have 2 mounts sharing the
> superblock?
>
> --
> Jeff Layton <jlayton@redhat.com>



-- 
Thanks,

Steve

Re: Mount failure due to restricted access to a point along the mount path

[Pavel Shilovsky]

2013/5/14 Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> On Fri, 10 May 2013 10:27:54 -0400
> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> On Fri, 10 May 2013 16:13:30 +0200
>> Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> wrote:
>>
>> > Hi,
>> >
>> > A while ago this was discussed:
>> >
>> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >
>> > This is essentially a regression introduced by the shared superblock
>> > changes in 3.0 and several SUSE customers are complaining about it.
>> > I've created a temporary fix which reverts 29 commits related to the
>> > shared superblock changes.  It works, but it's obviously not a
>> > permanent fix, especially since we definitely don't want to diverge
>> > from mainline.
>> >
>> > Is this issue being worked on?  Don't other distros have similar reports?
>> >
>> > Thanks,
>> > Miklos
>>
>> I don't know of anyone currently working on it. There are a couple of
>> possible approaches to fixing it, I think:
>>
>> 1) if the dentries to get down to the root of the mount don't already
>> exist, then attach some sort of "placeholder" inode that can be fleshed
>> out later if and when the dentry is accessed via other means.
>>
>> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> a bit more complicated due to the fact that the server may not hand out
>> real inode numbers and we sometimes have to fake them up.
>>
>> #1 is probably simpler to implement, but I'll confess that I haven't
>> thought through all of the potential problems with it.
>>
>
> So, giving this some more thought, I think #2 is really the correct way
> to fix this. Here's the main problem though:
>
> Suppose someone mounts:
>
>     //server/share/foo/bar/baz
>
> We make the sb->s_root point to the top level share, and then create a
> disconnected dentry for "baz" to return from ->mount.
>
> Then, a little while later, //server/share gets mounted separately and
> a user walks down to /foo/bar/baz within the same share.
>
> How do we ensure that we don't end up with two "baz" dentries in this
> situation? With NFS, we can be reasonably sure that there's a 1:1
> correspondance of filehandle to inode.
>
> Under CIFS, it's possible that it's faking up inode numbers if the
> server doesn't provide them via a UniqueID field. The only real
> identifying info we have for the inode in that case is the pathname.
>
> Perhaps we'd be best off to just rip out the sb sharing after all.
> Getting all of the corner cases right when the protocol and server
> implementations are so problematic is really, really difficult.
>
> If we do go that route, then the fscache code will need some work since
> it uses the sharename as a sb cookie.

Another option is to add mount options shared and nonshared (default)
like NFS already has and let users use
sharing capability if the permissions on server allow walking through
a share path to a mount root.

--
Best regards,
Pavel Shilovsky.

Re: Mount failure due to restricted access to a point along the mount path

[Pavel Shilovsky]

2013/5/14 Jeff Layton <jlayton@redhat.com>:
> On Fri, 10 May 2013 10:27:54 -0400
> Jeff Layton <jlayton@redhat.com> wrote:
>
>> On Fri, 10 May 2013 16:13:30 +0200
>> Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> > Hi,
>> >
>> > A while ago this was discussed:
>> >
>> >   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>> >
>> > This is essentially a regression introduced by the shared superblock
>> > changes in 3.0 and several SUSE customers are complaining about it.
>> > I've created a temporary fix which reverts 29 commits related to the
>> > shared superblock changes.  It works, but it's obviously not a
>> > permanent fix, especially since we definitely don't want to diverge
>> > from mainline.
>> >
>> > Is this issue being worked on?  Don't other distros have similar reports?
>> >
>> > Thanks,
>> > Miklos
>>
>> I don't know of anyone currently working on it. There are a couple of
>> possible approaches to fixing it, I think:
>>
>> 1) if the dentries to get down to the root of the mount don't already
>> exist, then attach some sort of "placeholder" inode that can be fleshed
>> out later if and when the dentry is accessed via other means.
>>
>> 2) do something like what NFS does (see commit 54ceac45). This becomes
>> a bit more complicated due to the fact that the server may not hand out
>> real inode numbers and we sometimes have to fake them up.
>>
>> #1 is probably simpler to implement, but I'll confess that I haven't
>> thought through all of the potential problems with it.
>>
>
> So, giving this some more thought, I think #2 is really the correct way
> to fix this. Here's the main problem though:
>
> Suppose someone mounts:
>
>     //server/share/foo/bar/baz
>
> We make the sb->s_root point to the top level share, and then create a
> disconnected dentry for "baz" to return from ->mount.
>
> Then, a little while later, //server/share gets mounted separately and
> a user walks down to /foo/bar/baz within the same share.
>
> How do we ensure that we don't end up with two "baz" dentries in this
> situation? With NFS, we can be reasonably sure that there's a 1:1
> correspondance of filehandle to inode.
>
> Under CIFS, it's possible that it's faking up inode numbers if the
> server doesn't provide them via a UniqueID field. The only real
> identifying info we have for the inode in that case is the pathname.
>
> Perhaps we'd be best off to just rip out the sb sharing after all.
> Getting all of the corner cases right when the protocol and server
> implementations are so problematic is really, really difficult.
>
> If we do go that route, then the fscache code will need some work since
> it uses the sharename as a sb cookie.

Another option is to add mount options shared and nonshared (default)
like NFS already has and let users use
sharing capability if the permissions on server allow walking through
a share path to a mount root.

--
Best regards,
Pavel Shilovsky.

Re: Mount failure due to restricted access to a point along the mount path

[Shirish Pargaonkar]

So instead of breaking superblock sharing and fscache functionality
with 2), it may be better off to explore 1).  Will spend some time doing so.

Regards,

Shirish

On Fri, May 10, 2013 at 9:27 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 10 May 2013 16:13:30 +0200
> Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> wrote:
>
>> Hi,
>>
>> A while ago this was discussed:
>>
>>   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>>
>> This is essentially a regression introduced by the shared superblock
>> changes in 3.0 and several SUSE customers are complaining about it.
>> I've created a temporary fix which reverts 29 commits related to the
>> shared superblock changes.  It works, but it's obviously not a
>> permanent fix, especially since we definitely don't want to diverge
>> from mainline.
>>
>> Is this issue being worked on?  Don't other distros have similar reports?
>>
>> Thanks,
>> Miklos
>
> I don't know of anyone currently working on it. There are a couple of
> possible approaches to fixing it, I think:
>
> 1) if the dentries to get down to the root of the mount don't already
> exist, then attach some sort of "placeholder" inode that can be fleshed
> out later if and when the dentry is accessed via other means.
>
> 2) do something like what NFS does (see commit 54ceac45). This becomes
> a bit more complicated due to the fact that the server may not hand out
> real inode numbers and we sometimes have to fake them up.
>
> #1 is probably simpler to implement, but I'll confess that I haven't
> thought through all of the potential problems with it.
>
> --
> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Mount failure due to restricted access to a point along the mount path

[Shirish Pargaonkar]

So instead of breaking superblock sharing and fscache functionality
with 2), it may be better off to explore 1).  Will spend some time doing so.

Regards,

Shirish

On Fri, May 10, 2013 at 9:27 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 10 May 2013 16:13:30 +0200
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>> Hi,
>>
>> A while ago this was discussed:
>>
>>   http://thread.gmane.org/gmane.linux.kernel.cifs/7779
>>
>> This is essentially a regression introduced by the shared superblock
>> changes in 3.0 and several SUSE customers are complaining about it.
>> I've created a temporary fix which reverts 29 commits related to the
>> shared superblock changes.  It works, but it's obviously not a
>> permanent fix, especially since we definitely don't want to diverge
>> from mainline.
>>
>> Is this issue being worked on?  Don't other distros have similar reports?
>>
>> Thanks,
>> Miklos
>
> I don't know of anyone currently working on it. There are a couple of
> possible approaches to fixing it, I think:
>
> 1) if the dentries to get down to the root of the mount don't already
> exist, then attach some sort of "placeholder" inode that can be fleshed
> out later if and when the dentry is accessed via other means.
>
> 2) do something like what NFS does (see commit 54ceac45). This becomes
> a bit more complicated due to the fact that the server may not hand out
> real inode numbers and we sometimes have to fake them up.
>
> #1 is probably simpler to implement, but I'll confess that I haven't
> thought through all of the potential problems with it.
>
> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Mount failure due to restricted access to a point along the mount path

[Steve French]

On Mon, Feb 4, 2013 at 1:41 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Mon, 04 Feb 2013 21:04:21 +0530
> Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> wrote:
>
> > Hi all,
> >
> > I have been looking at the $SUBJECT. And there is already a bug reported
> > in the samba.org bugzilla
> >
> > https://bugzilla.samba.org/show_bug.cgi?id=8950
> >
> > cifs gets "Access denied" while trying to get the root inode. Suppose if
> > you are trying to mount /share/dir/subdir and if the user doesn't have
> > access to any of point along the path ie. /share or /dir, mount will
> > fail.
> >
> > As noted by Jeff Layton in the bug report, this seems to be a known
> > problem since we started using the shared superblock model. Though we
> > can work around this problem by providing neccessary permissions for the
> > entire path, users consider this as a regression. I tend to agree with
> > them and think that may be we should have addressed this problem before
> > pushing the shared superblock changes.
> >
> > From the changelog it appears that this results in better performance
> > when we use SMB2.1 leases. How much better performance we are seeing?
> > Is that worth living with this regression?
> >
> > Does this affect the CIFS users who are not using SMB2.1 in anyway?
> >
> >
> > Thanks
> >
>
> Well, more than that, it's a cache coherency thing. If you have an
> inode that's reachable via 2 mounts, you want the caches to be coherent
> between the two. Note that superblock sharing was a requirement for the
> fscache patches NFS, so I was never clear why that wasn't the case for
> CIFS...
>
> In any case, yes this is a problem regardless of CIFS version in use.
>
> What we probably ought to do is come up with a way to instantiate the
> intermediate dentries with "dummy" inodes at mount time. Those will need
> to be revalidated (and rehashed) if they ever come to life suddenly
> though.

Agreed


--
Thanks,

Steve

Re: Mount failure due to restricted access to a point along the mount path

[Jeff Layton]

On Mon, 04 Feb 2013 21:04:21 +0530
Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> wrote:

> Hi all,
> 
> I have been looking at the $SUBJECT. And there is already a bug reported
> in the samba.org bugzilla
> 
> https://bugzilla.samba.org/show_bug.cgi?id=8950
> 
> cifs gets "Access denied" while trying to get the root inode. Suppose if
> you are trying to mount /share/dir/subdir and if the user doesn't have
> access to any of point along the path ie. /share or /dir, mount will fail.
> 
> As noted by Jeff Layton in the bug report, this seems to be a known
> problem since we started using the shared superblock model. Though we
> can work around this problem by providing neccessary permissions for the
> entire path, users consider this as a regression. I tend to agree with
> them and think that may be we should have addressed this problem before
> pushing the shared superblock changes.
> 
> From the changelog it appears that this results in better performance
> when we use SMB2.1 leases. How much better performance we are seeing?
> Is that worth living with this regression?
> 
> Does this affect the CIFS users who are not using SMB2.1 in anyway?
> 
> 
> Thanks
> 

Well, more than that, it's a cache coherency thing. If you have an
inode that's reachable via 2 mounts, you want the caches to be coherent
between the two. Note that superblock sharing was a requirement for the
fscache patches NFS, so I was never clear why that wasn't the case for
CIFS...

In any case, yes this is a problem regardless of CIFS version in use.

What we probably ought to do is come up with a way to instantiate the
intermediate dentries with "dummy" inodes at mount time. Those will need
to be revalidated (and rehashed) if they ever come to life suddenly
though.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Mount failure due to restricted access to a point along the mount path

[Suresh Jayaraman]

Hi all,

I have been looking at the $SUBJECT. And there is already a bug reported
in the samba.org bugzilla

https://bugzilla.samba.org/show_bug.cgi?id=8950

cifs gets "Access denied" while trying to get the root inode. Suppose if
you are trying to mount /share/dir/subdir and if the user doesn't have
access to any of point along the path ie. /share or /dir, mount will fail.

As noted by Jeff Layton in the bug report, this seems to be a known
problem since we started using the shared superblock model. Though we
can work around this problem by providing neccessary permissions for the
entire path, users consider this as a regression. I tend to agree with
them and think that may be we should have addressed this problem before
pushing the shared superblock changes.

>From the changelog it appears that this results in better performance
when we use SMB2.1 leases. How much better performance we are seeing?
Is that worth living with this regression?

Does this affect the CIFS users who are not using SMB2.1 in anyway?


Thanks

-- 
Suresh Jayaraman