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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 May 2013 10:27:54 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-cifs@...r.kernel.org, Steve French <smfrench@...il.com>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	sjayaraman@...ell.com
Subject: Re: Mount failure due to restricted access to a point along the
 mount path

On Fri, 10 May 2013 16:13:30 +0200
Miklos Szeredi <miklos@...redi.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@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/