[openstack-dev] [TripleO] a need to assert user ownership in preserved state

Clint Byrum clint at fewbar.com
Tue Oct 7 21:32:42 UTC 2014


Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700:
> Hi
> 
> > On 7 Oct 2014, at 20:47, Clint Byrum <clint at fewbar.com> wrote:
> >> 
> >> I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds.
> > Disagree on the grounds that the point of this is to deal with people
> > who already have images and want to update them. We're not trying to
> > enable people to deploy radically different OS's or anything like that.
> 
> My point is that we don't know what else is changing under the hood. Switching OS is a bit extreme, but we don't know that they're not going to pull in an OS upgrade at the same time and have everything change substantially, or even just introduce one additional dependency which we would destroy the uid/gid for.
> 

Ok, any time we can fail at build time is good, so merging is important. I agree now.

> >> I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each.
> >> The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen).
> >> 
> > 
> > That is a lot of complexity for the case that we don't want people to
> > use (constantly carrying /etc/passwd and /etc/group forward).
> 
> As tchaypo pointed out on IRC, if we do this static route, we are laying down a great big concrete slab of opinion in our images. I'm all for opinionated software, but we need to give people an out, which means we probably want to have a way for the suggested default UID/GIDs to be overridden, i.e. roughly what I described. We can just use that override to inject the pre-existing passwd/group values, if we so desire.
> 

Mmk. I think having an override is important, but I feel that we can do it
in a more straight forward manner. I may not have thought it all the way
through.



More information about the OpenStack-dev mailing list