> -----Original Message-----
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 02 October 2014 02:51
> To: openstack-dev
> Subject: [openstack-dev] [TripleO] a need to assert user ownership in
> preserved state
> Recently we've been testing image based updates using TripleO, and we've
> run into an interesting conundrum.
> Currently, our image build scripts create a user per service for the
> image. We don't, at this time, assert a UID, so it could get any UID in
> the /etc/passwd database of the image.
> However, if we add a service that happens to have its users created
> before a previously existing service, the UID's shift by one. When this
> new image is deployed, the username might be 'ceilometer', but
> /mnt/state/var/lib/ceilometer is now owned by 'cinder'.
> Here are 3 approaches, which are not mutually exclusive to one another.
> There are likely others, and I'd be interested in hearing your ideas.
> * Static UID's for all state-preserving services. Basically we'd just
>   allocate these UID's from a static pool and those are always the UIDs
>   no matter what. This is the simplest solution, but does not help
>   anybody who is already looking to update a TripleO cloud. Also, this
>   would cause problems if TripleO wants to merge with any existing
>   system that might also want to use similar UID's. This also provides
>   no guard against non-static UID's storing things on the state
>   partition.
> * Fix the UID's on image update. We can backup /etc/passwd and
>   /etc/group to /mnt/state, and on bootup we can diff the two, and any
>   UIDs that changed can be migrated. This could be very costly if the
>   swift storage UID changed, with millions of files present on the
>   system. This merge process is also not atomic and may not be
>   reversible, so it is a bit scary to automate this.
> * Assert ownership when registering state path. We could have any
>   state-preserving elements register their desire for any important
>   globs for the state drive to be owned by a particular symbolic
>   username. This is just a different, more manual way to fix the UID's
>   and carries the same cons.

For these last two cases, of fixing the file ownership on first boot based on 
the previous UIDs of a username, why would we decide to fix the data files?

If instead we were to change the UIDs such that the data files were correct, 
the only thing to fix up would be the installed files in the image, which are a 
well-defined and limited set of files.

> So, what do people think?
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Jon-Paul Sullivan ☺ Cloud Services - @hpcloud

Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's 
Quay, Dublin 2. 
Registered Number: 361933
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error you should 
delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should 
consider this message and attachments as "HP CONFIDENTIAL".
OpenStack-dev mailing list

Reply via email to