The home of root

[Kyle Fazzari]

+1 here too.

On 01/07/2016 01:57 PM, John Lenton wrote:
> +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
>>
> 

--
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
kyle at canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160107/ddf700c0/attachment-0001.pgp>