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] [day] [month] [year] [list]
Date:	Thu, 4 Dec 2008 16:33:36 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Bryan Donlan <bdonlan@...il.com>
Cc:	mtk.manpages@...il.com, ebiederm@...ssion.com,
	lkml <linux-kernel@...r.kernel.org>, linux-man@...r.kernel.org,
	clg@...ibm.com, herbert@...hfloor.at, dev@...ru,
	Subrata Modak <subrata@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>
Subject: Re: Could you write some CLONE_NEWUSER?

Quoting Bryan Donlan (bdonlan@...il.com):
> This is something more of a general question than one about this
> manpage, but how will files owned by user namespaces be represented on
> the underlying filesystem? Since (C, 501) will be meaningless after a
> reboot at the latest, it makes little sense to persist them...

Yeah that's a very interesting question.  Clearly persistant names for
the user namespaces are needed.  Eric very much wanted to avoid having
the user namespaces be explicitly named, so we pursued the path of
having the filesystem handle the naming.  So in my last patchset,
a mount option could register the mounter's user namespace name.
There would be a system-wide policy saying for instance that (B,500)
user namespaces owned by can register themselves at C.

(end of discussion arising from that patchset is here: )
https://lists.linux-foundation.org/pipermail/containers/2008-August/012793.html

In the simplest case of no fs support for user namespaces, the mount
will be 'owned' by the userns which mounted it (no persistant name
needed for that).  Users who are in a different namespace will only get
the 'user other' permission to the file/dir, and may not create files
there (since we wouldn't know which userid to place on it).

Then the fs can support user namespaces - however it wants.  It could
just store (B, 500),(C, 501) in an xattr.  Or it could just store the
userid and userns name of the lowest user (I.e. C and 0), and count on
knowning that (B, 500) owns user namespace C.  We do want to provide
generic helpers in lib/fsuserns.c which any fs could use.

But yes, picking a meaningful persistant name for a user namespace
is an issue.

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

Powered by blists - more mailing lists