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@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@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@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@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@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