linux-kernel - Re: [PATCH 1/2] autofs4: allow autofs to work outside the initial PID namespace

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]

Message-ID: <874nkgwfw0.fsf@tucsk.pomaz.szeredi.hu>
Date:	Fri, 23 Nov 2012 15:30:39 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Ian Kent <raven@...maw.net>
Cc:	autofs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, sukadev@...ux.vnet.ibm.com,
	serge.hallyn@...onical.com, ebiederm@...ssion.com
Subject: Re: [PATCH 1/2] autofs4: allow autofs to work outside the initial PID namespace

Ian Kent <raven@...maw.net> writes:

> On Fri, 2012-11-23 at 11:45 +0800, Ian Kent wrote:
>> On Thu, 2012-11-22 at 17:24 +0100, Miklos Szeredi wrote:
>> > Patches were tested by the customer.
>> > 
>> > Ian, Eric, do these patches look OK?
>> 
>> They look OK to me but I'm still a bit concerned about changing the way
>> this behaves, but I also believe this is the way we want it to behave.
>
> OK, I ran the autofs Connectathon tests that I often use on a kernel
> with these patches and they worked fine. So, AFAICS. the patches
> shouldn't introduce regressions.

And the reason for that is the patches introduce no behavioral changes
at all if the automount daemon was started in the initial namespace.

They only change (and fix) semantics of the case when automount is
started in a cloned pid namespace.

>
>> 
>> Give me a little bit more time to run a simple test to ensure we can at
>> least do what we could previously, and that's nothing more than
>> umounting duplicated mounts (which probably shouldn't be duplicated at
>> all) in the container.
>
> Interestingly the simple container test program I have also worked in
> the same way it does on current kernels so again I didn't see a problem
> adding the patches.
>
> But I do have a couple of questions that are a little related.
>
> Calling clone(2) with flags
> CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET
> will result in a copy of the existing set of mounts. The autofs mounts
> can be umounted if they are not needed.
>
> But, on Fedora systemd sets "/" as shared at boot which prevents the
> umount of these autofs mounts, unless you mark "/" as private in the
> clone, after which the mounts can be umounted.
>
> Does having "/" marked as shared in the root namespace mean that further
> mounts in the root namespace will also appear in the clone and that
> mounts done in the clone will appear in the root namespace?

Yes.

>
> Will mounting all autofs mounts with MS_PRIVATE prevent the autofs
> mounts and any mounts under them from appearing in the root namespace?

Changing autofs mounts to MS_PRIVATE will prevent submounts of these
from being propagated to/from the root namespace.

>
> I assume there is no way for autofs to stop the propagation from the
> root namespace, is that correct?

Not for the children of the shared mount.  For the children of the
autofs mounts, they can be prevented, which is really what you want, I
guess.

Thanks,
Miklos

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