The home of root

[John Lenton]

+1 to using euid's home always \o/

On 7 January 2016 at 18:02, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> 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
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>