The home of root

[Gustavo Niemeyer]

Hello again,

We have a trivial but well entangled problem about where to store files for
the root user.

I'll offer a more comprehensive view of the issue, provide some data points
for further reading, and finally invite opinions on a strawman proposal for
moving forward.

Some initial context: snappy applications may store data in two different
places: the per-snap data directory, and the per-snap per-user data
directory. Again, one of them is unique for the snap, the other is unique
for each snap+user pair. The per-snap directory is easy to deal with. For
the per-snap per-user data, we create a directory inside the user's $HOME
specific to the given snap, and that also works well in general.

Unfortunately, though, the root user has a few special characteristics that
break that logic. So far, we found the following issues to think through:

1. When using sudo, $HOME traditionally points to the real user's home, not
to the effective user's. This is the cause of much frustration when files
under the user's home end up owned by root or some other user. Next time
the application is run without the foreign privileges, it breaks for being
unable to access/remove/etc the created data. This behavior is of course
handy in some cases, when we want the application (say, our editors) to
read configuration from our own homes, but it breaks down when these same
applications decide to write into them.

2. Some applications run as services expected to find the user data
directory to work with, since they did so in other circumstances already.
The initial design didn't predict this fact, and those ended up breaking
for being unable to access the root's $HOME for dumping that data. We could
take the stance that this was an incorrect access by the application, but
that means breaking the application for no greater good.

3. As a different angle to the prior point, it may sound awkward to see a
service dumping data into the root's home. It was suggested that services
would have their user home set under /var/lib, which implies that either
the same application, running as the same user (root), would have two
different homes depending on context (service vs. non-service). Or
alternatively that the root's $HOME would sit elsewhere for both cases.

By now we have had these discussions online, threads in the tracker, and
threads in multiple pull requests filed addressing small portions of the
problem each.

Here are some references:

https://bugs.launchpad.net/snappy/+bug/1466234
https://bugs.launchpad.net/snappy/+bug/1527612
https://github.com/ubuntu-core/snappy/pull/264
https://github.com/ubuntu-core/snappy/pull/269

With all that context, I'd like to propose a theory: all of that comes from
a weak convention of what $HOME means. With snappy, though, we're being
much more prescriptive about the environment under which applications run,
to the point of constraining them further security-wise. So, this feels
like a good chance for us to cut out that ambiguity, and be clear: when we
start an application, $HOME must point to the effective user's home, and
the snap user data directory should follow along. If an application runs as
root, the rule doesn't change. If an application runs as a service, as
root, the rule doesn't change either.

That cleans up the situation on points 1, 2, and 3. Perhaps it won't make
everybody happy, but it's a clear rule that is easy to understand, and
prevents awkward breakage as described in points 1 and 2.

How does that sound?  Should we move forward with that?


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160107/9644b1e4/attachment.html>