On Mon, 27.06.11 17:32, Ludwig Nussel (ludwig.nus...@suse.de) wrote:
>
> Lennart Poettering wrote:
> > On Mon, 27.06.11 14:50, Michal Vyskocil (mvysko...@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 (mvysko...@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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
