linux-kernel - Re: [patch] unprivileged mounts update

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: <20070426194225.GA11038@sergelap.austin.ibm.com>
Date:	Thu, 26 Apr 2007 14:42:25 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	serge@...lyn.com, hpa@...or.com, linuxram@...ibm.com,
	linux-kernel@...r.kernel.org, containers@...ts.osdl.org,
	linux-security-module@...r.kernel.org, ebiederm@...ssion.com,
	viro@....linux.org.uk, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [patch] unprivileged mounts update

Quoting Miklos Szeredi (miklos@...redi.hu):
> > So then as far as you're concerned, the patches which were in -mm will
> > remain unchanged?
> 
> Basically yes. I've merged the update patch, which was not yet added
> to -mm, did some cosmetic code changes, and updated the patch headers.
> 
> There's one open point, that I think we haven't really explored, and
> that is the propagation semantics.  I think you had the idea, that a
> propagated mount should inherit ownership from the parent into which
> it was propagated.

Don't think that was me.  I stayed out of those early discussions
because I wasn't comfortable guessing at the proper semantics yet.

But really, I, as admin, have to set up both propagation and user mounts
for a particular subtree, so why would I *not* want user mounts to be
propagated?

So, in my own situation, I have done

	make / rshared
	mount --bind /share /share
	make /share unbindable
	for u in $users; do
		mount --rbind / /share/$u/root
		make /share/$u/root rslave
		make /share/$u/root rshared
		mount --bind -o user=$u /share/$u/root/home/$u /share/$u/root/home/$u
	done

All users get chrooted into /share/$USER/root, some also get their own
namespace.  Clearly if a user in a new namespace does

	mount --bind -o user=me ~/somedir ~/otherdir

then logs out, and logs back in, I want the ~/otherdir in the new
namespace (and the one in the 'init' namespace) to also be owned by
'me'.

> That sounds good if everyone agrees?

I've shown where I think propagating the mount owner is useful.  Can you
detail a scenario where doing so would be bad?  Then we can work toward
semantics that make sense...

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