[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: concerns about Salsa

On Sat, 2018-06-09 at 13:52 +0100, Ian Jackson wrote:
> As a service owner who has chosen to run the service out of git
> for other reasons, I don't really care.  But someone who wants to run
> the service from packages might have a different view.

In my very limited experience with containers they don't need
the host privileges that come with root.  The only reason containers
want root is to continue doing privilege separation (eg, prevent the
web from installing packages) in the way they've always done it.  For
example a fakeroot that persisted across reboots and somehow worked
with ldd / ld.so would be fine.  

It turns out if this is all you need its already available.  Some
container systems can already map root inside of the container to a
less privileged user outside of the container.  Docker for example [0].

And it is generally all you need. A container seems to reduce to:

- Program(s) that run in their own little ephemeral POSIX universe
  (ephemeral in the sense when it is stopped all internal state is
  lost, as if it was stored in RAM and the power was cycled) that
  has no connections with the outside world whatsoever, except:

- They listen to TCP/UCP ports inside the container.  But these are
  completely isolated from the outside world until the sysadmin
  connects an outside IP Address / port to them, and

- Stores data that should be persisted or perhaps just visible (eg
  logs) in a few well known directories, onto which the sysadmin can
  bind mount appropriate storage (the convention seems to be /data),

- Has unfettered access to the network as a client. 

Root is either not required for these things or easily avoided.  For
example even though the external world connects to Salsa on port 80 and
it would require root privileges to listen on port 80, Salsa can listen
on port 8888 inside the container and if the sysadmin wants it to serve
port 80, he maps some_ip_addr:80 to the container 8888.

There are inefficiencies built into this system.  For example you may
end up with 100 containers all polling Debian for security updates and
installing them into ephemeral little worlds.  But these inefficiencies
don't seem like good reason to avoid using containers.

[0] https://docs.docker.com/engine/security/userns-remap/#user-namespace-known-limitations

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: