Re: "Too many levels of symbolic links"

[Ian Kent <raven@themaw.net>]

On Wed, 2016-03-09 at 18:44 +0100, Donald Buczek wrote:
> Hi, Kent,
> 
> in 2014 we analyzed and discussed a problem which in my view boiled
> down 
> to "autofs refuses to mount on a path (dentry) which already is
> mounted 
> in another namespace." This is because it uses d_mountpoint ( = 
> DCACHE_MOUNTED) to decide whether a mount should be attempted or not.
> At 
> that point I selfishly changed our setting to avoid use of mount 
> namespaces and left you alone with the problem.
> 
> But now we need mount namespaces ourselves using kernel 4.4.2 and the 
> old problem reoccurred
> 
> So my questions:
> 
> * am I right, that this problem is still unresolved?
> * is this considered a bug?

I originally made a couple of patches to make autofs namespace aware for
this case but I'm still holding on to them because, as I did them, I
realized there's quite a bit more going on with this.

For example, suppose autofs is namespace aware, the autofs file system
has been cloned as part of the namespace creation, the filesystem in the
new namespace is propagation private and the automount daemon is running
in the root namespace.

In this case there's no limit on the number of times the namespace can
attempt to trigger a mount which is possibly open to be used as a denial
of service attack. So the current ELOOP behaviour is probably needed in
this case.

Another example, assume the automount daemon is running in the root
namespace, there are multiple containers where an indirect mount map has
been passed as a volume and the container implementation sets it's
mounts as propagation slave.

In this case the mounts are mounted in the root namespace and propagated
to the containers. And similarly, if there's a bad mount the containers
are capped on the number of mount attempts by the current ELOOP
behaviour. But ELOOP probably isn't the error return the containers
should be getting either and allowing unabated callbacks is probably not
good either.

There are more cases, some of which I haven't properly investigated.

So I ended up holding onto the patches.

What exactly is your usage need?

Ian
--
To unsubscribe from this list: send the line "unsubscribe autofs" in