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]

Message-Id: <E1HdNwV-0006l2-00@dorka.pomaz.szeredi.hu>
Date:	Mon, 16 Apr 2007 11:56:15 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	linuxram@...ibm.com
CC:	miklos@...redi.hu, devel@...nvz.org, serue@...ibm.com,
	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

> > > Also for bind-mount and remount operations the flag has to be propagated
> > > down its propagation tree.  Otherwise a unpriviledged mount in a shared
> > > mount wont get reflected in its peers and slaves, leading to unidentical
> > > shared-subtrees.
> > 
> > That's an interesting question.  Do we want shared mounts to be
> > totally identical, including mnt_flags?  It doesn't look as if
> > do_remount() guarantees that currently.
> 
> Depends on the semantics of each of the flags. Some flags like of the
> read/write flag, would not interfere with the propagation semantics
> AFAICT.  But this one certainly seems to interfere.

That depends.  Current patches check the "unprivileged submounts
allowed under this mount" flag only on the requested mount and not on
the propagated mounts.  Do you see a problem with this?

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/