[systemd-devel] [PATCH] nspawn: spawn shell under specified --user

[Lennart Poettering]

On Mon, 27.06.11 17:32, Ludwig Nussel (ludwig.nussel at suse.de) wrote:

> 
> Lennart Poettering wrote:
> > On Mon, 27.06.11 14:50, Michal Vyskocil (mvyskocil at suse.cz) wrote:
> > 
> > > On Mon, Jun 27, 2011 at 02:01:27PM +0200, Lennart Poettering wrote:
> > > > On Fri, 24.06.11 14:39, Michal Vyskocil (mvyskocil at suse.cz) wrote:
> > > > 
> > > > > Add -u/--user option, which changes the effective and real user and
> > > > > group id to the new value. The user must exists in the chroot, otherwise
> > > > > it will fail. Both username and user id are accepted.
> > > > 
> > > > Sounds sensible, though I do wonder about the ultimate usefulness of
> > > > this given that this requires user settings configured on the host
> > > > systems in a way that makes sense in the container too. (i.e. the $HOME
> > > > and UID/GID of the user must be in sync in host and in container). Or am
> > > > I missing something?
> > > 
> > > Yes, that's the requirements - user must exists in chroot. But I don't
> > > see any need why the uid/gid must be the same. All things are done after
> > > chroot("."), so in the context of container.
> 
> Not necessarily. If there's a connection to nscd open you will keep
> talking to the host.
> http://lists.rpm.org/pipermail/rpm-maint/2011-May/003010.html

Well, but we do not really do any other NSS call, and since NSS is
initialized lazily we should be safe.

> Also keep in mind that you are loading shared libs from the chroot
> into the process which is still running as root. So name based user
> switching is not a security feature.

Well, the man page already clarifies that nspawn is in no way secure. So
I am not too concerned about this. 

Michal's patch adds an optional argument --user. It might be worth
explaining in the man page that by using this you are running into
certain risks.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.