<div dir="ltr"><div>Dmitry,</div><div><br></div><div>I mean, currently shotgun fetches services' configuration along with astute.yaml. These files contain passwords, keys, tokens. I beleive, these should be sanitized. Or, better yet, there should be an option to sanitize sensitive data from fetched files.</div><div><br></div><div><br></div>Aleksandr,<div><br></div><div>Currently Fuel has a service non-root account with passwordless sudo enabled. This may change in the future (the passwordless part), however, now I don't see an issue there.</div><div>Additionally, it is possible for users to configure sudo for the user-facing account however they like.</div><div><br></div><div>In regards to have this tool to use a non-root accounts, there are 2 items:</div><div>- execute commands, that require elevated privileges (the easy part -- user has to be able to execute these commands with sudo and without password)</div><div>- copy files, that this user doesn't have read privileges for.</div><div><br></div><div>For the second item, there are 2 possible solutions:</div><div>1. Give the non-root user read privileges for these files.</div><div>Pros:</div><div>- More straightforward, generally acceptable way</div><div>Cons:</div><div>- Requires additional implementation to give permissions to the user</div><div>- (?) Not very extensible: to allow copying a new file, we'd have to first add it to the tool's config, and somehow implement adding read permissions</div><div><br></div><div>2. Somehow allow to copy these files with sudo.</div><div>Pros:</div><div>- More simple implementation: we'll just need to make sure that the user can do passwordless sudo</div><div>- Extensible: to add more files, it's enough to just specify them in the tool's configuration.</div><div>Cons:</div><div>- Non-obvious, obscure way</div><div>- Relies on having to be able to do something like "sudo cat /path/to/file", which is not much better that just giving the user read privileges. In fact, the only difference between this and giving the user the read rights is that it is possible to allow "sudo cat" for files, that don't yet exist, whereas giving permissions requires that these files already are on the filesystem.</div><div><br></div><div>What way do you think is more appropriate? </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 5:28 AM, Aleksandr Dobdin <span dir="ltr"><<a href="mailto:adobdin@mirantis.com" target="_blank">adobdin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dmitry,</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><span>You can create a non-root user account without
root privileges but you need to add it to appropriate groups and
configure sudo permissions (even though you add this user to root group,
it will fail with iptables command for example) to get config files and
launch requested commands.<span></span></span><span>I
suppose that it is possible to note this possibility in the
documentation and provide a customer with detailed instructions on how
to setup this user account.<span></span></span><span>There are some logs that will also be missing from the snapshot with the message <code></code></span><span><code>permission denied</code></span><span> (only the root user has access to some files with 0600 mask)<br>This user account could be specified into config.yaml (ssh -> opts option)</span><br></div><span class=""><div class="gmail_default" style="font-family:tahoma,sans-serif"><span><br></span></div><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font size="2"><span style="font-family:tahoma,sans-serif">Sincerely yours,<br>Aleksandr Dobdin<br>Senior Operations Engineer<br>Mirantis <div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">Inc.</div></span></font><span style="font-family:monospace,monospace"><br></span></div></div></div></div></div></div></div>
</span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>