[LEDE-DEV] running stuff as !root

[Conor O'Gorman]

On 18/05/16 08:41, David Lang wrote:
> On Wed, 18 May 2016, John Crispin wrote:
>
>> On 18/05/2016 09:04, David Lang wrote:
>>>
>>> The first question I would have is if we are going to the system users
>>> in an essentially random order (as needed so two systems with the same
>>> packages installed in a different order have different user->uid
>>> mapping) or if we are going to define service accounts distro wide so
>>> they are always going to be the same.
>>
>>
>> what would be the pros and cons for either of those ?
>
> If you have static user allocations then LEDE needs to maintain a 
> central repository of userids and a way for applications to be 
> registered with it.
>
> If you have dynamic user allocations, then the package installer 
> scripts need to have more complexity to request the userids on the fly 
> and make everything they install have the correct permissions. (most 
> distros take this approach)
>
> In the case of LEDE, we generally aren't running install scripts for 
> the packages on a running system, all this happens at compile time 
> when you don't have a way to run various tools to lookup and allocate 
> users and set the file permissions, so I think there's a good argument 
> that the static allocation approach would work better here.
>
> The other place where this bites people is when they have multiple 
> systems that then need to start working together (mounting a network 
> drive and sharing info, think high availability and similar, or 
> copying files from one system to another and trying to use them 
> there). The 'normal' answer is that you then need to start managing 
> users with some new tool (Chef, Puppet, Ansible, Salt, etc) that 
> pre-allocates the users onto the systems before the install scripts 
> run and/or overrides the package defaults.
>
>
> As I say, the common choice is dynamically allocated uids, but lede 
> has to do this at compile/image creation time instead of on a running 
> system.
I believe that during the root filesystem generation, scripts are run 
and some information is available. Dependencies and ordering may be an 
issue.

Conor