linux-kernel - Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag

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:	Thu, 19 Apr 2007 10:36:15 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	linuxram@...ibm.com
CC:	serue@...ibm.com, devel@...nvz.org, linux-kernel@...r.kernel.org,
	containers@...ts.osdl.org, viro@....linux.org.uk,
	linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [Devel] Re: [patch 05/10] add "permit user mounts in new
	namespace" clone flag

> > > As I said earlier, I see a case where two mounts that are peers of each
> > > other can become un-identical if we dont propagate the "allowusermnt".
> > > 
> > > As a practical example.
> > > 
> > > /tmp and /mnt are peers of each other.
> > > /tmp has its "allowusermnt" flag set, which has not been propagated
> > > to /mnt.
> > > 
> > > now a normal-user mounts an ext2 file system under /tmp at /tmp/1
> > > 
> > > unfortunately the mount wont appear under /mnt/1 
> > 
> > Argh, that is not true.  That's what I've been trying to explain to
> > you all along.
> 
> I now realize you did, but I failed to catch it. sorry :-(

It is my fault also.  I will add better description to the patch
headers.

> > The propagation will be done _regardless_ of the flag.  The flag is
> > only checked for the parent of the _requested_ mount.  If it is
> > allowed there, the mount, including any propagations are allowed.  If
> > it's denied, then obviously it's denied everywhere.
> > 
> > > and in case if you allow the mount to appear under /mnt/1, you will
> > > break unpriviledge mounts semantics which promises: a normal user will
> > > not be able to mount at a location that does not allow user-mounts.
> > 
> > No, it does not promise that.  The flag just promises, that the user
> > cannot _request_ a mount on the parent mount.
> 
> ok. if the ability for a normal user to mount something *indirectly*
> under a mount that has its 'allowusermnt flag' unset, 
> is acceptable under the definition of 'allowusermnt', i guess my only
> choice is to accept it. :-)

It is the only "sane" way I think.

Maybe the MS_SETFLAGS/MS_CLEARFLAGS mount operation could have an
option for propagating the given flag(s).  Then it's really up to the
sysadmin, to determine in each case what the desired behavior is.

Yes, you are right, that most of the time propagating the
"allowusermnt" between peers may be the right thing to do.  But for
example propagating it from master to slave may not be a good thing at
all.  So it shouldn't be for the kernel to decide.

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/