[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Container data and uid/gid
- From: "Stephen C. Tweedie" <sct redhat com>
- To: Colin Walters <walters verbum org>
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] Container data and uid/gid
- Date: Tue, 13 Jan 2015 16:12:08 +0000
Hi,
On Mon, 2015-01-12 at 18:03 -0500, Colin Walters wrote:
> On Wed, Jan 7, 2015, at 05:14 PM, Matt Micene wrote:
>
> > I may be overstating the case a bit, but ensuring uid/gid matches on
> > shared volumes (regardless of Docker or otherwise) has always been a
> > manual process.
>
> Right, generally. The current Fedora recommendations are here:
>
> https://fedoraproject.org/wiki/Packaging:UsersAndGroups
>
> Which let's be honest, "fork the setup package and add an Epoch" is
> pretty terribly ugly.
>
> So to reiterate briefly the reason manageable uid/gid allocation is
> important in Atomic is that:
>
> - Containers allow a lot of flexibility, except uid/gid is an anchor
> dragging it down
>
> - To implement atomic upgrades, rpm-ostree requires distinguishing
> locally added users from OS vendor users
Is it over-complicating things to expect the uid to be allocated by the
container or the container app?
There's a clear advantage to running a container as non-root. But
containers already have some level of isolation from each other; so do
we need a per-application uid?
It might well be enough just to have a single "docker" or "docker-app"
uid/gid, and run all containers using that same uid.
There would still be at least some reduction in security if you
accidentally share the same volume between the wrong containers... but
then, don't do that. And the advantage over running as root is still
huge (you're not running the app with write access to its entire
runtime), and it's easy to keep the uid consistent between the host and
its containers.
Or do we really need the uids to be per-app?
--Stephen
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]