Reviewed: https://review.openstack.org/352866
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=87530b6e674750ab0d55b70cce4d96bf26d1f49a
Submitter: Jenkins
Branch: master
commit 87530b6e674750ab0d55b70cce4d96bf26d1f49a
Author: Markus Zoeller <mzoel...@de.ibm.com>
Date: Tue Aug 9 13:55:54 2016 +0200
Don't attempt to escalate nova-manage privileges
Remove code which allowed nova-manage to attempt to escalate
privileges so that configuration files can be read by users who
normally wouldn't have access, but do have sudo access.
The privilege escalation came into nova-manage with commit e9fd01e
to solve bug 805695. That bug report didn't describe a faulty behavior
but a change request.
NOTE: This is related to change I03063d2 from Kiall Mac Innes who did
this for the "designate" project. I'm reusing the change-id from his
change to make it clear that they are related to each other.
NOTE: I removed the try-except block completely, as it doesn't make
sense to continue when we cannot read the config file (due to a wrong
path or permission errors). That's the same approach we used in the
recent "nova/cmd/policy_check" module.
https://github.com/openstack/nova/blob/master/nova/cmd/policy_check.py#L158
Co-Authored-By: Kiall Mac Innes <ki...@macinnes.ie>
Closes-Bug: 1611171
Change-Id: I03063d2af14015e6506f1b6e958f5ff219aa4a87
** Changed in: nova
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1611171
Title:
re-runs self via sudo
Status in Cinder:
Fix Released
Status in Designate:
In Progress
Status in ec2-api:
In Progress
Status in gce-api:
In Progress
Status in Manila:
In Progress
Status in masakari:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Security Advisory:
Won't Fix
Status in Rally:
In Progress
Bug description:
Hello, I'm looking through Designate source code to determine if is
appropriate to include in Ubuntu Main. This isn't a full security
audit.
This looks like trouble:
./designate/cmd/manage.py
def main():
CONF.register_cli_opt(category_opt)
try:
utils.read_config('designate', sys.argv)
logging.setup(CONF, 'designate')
except cfg.ConfigFilesNotFoundError:
cfgfile = CONF.config_file[-1] if CONF.config_file else None
if cfgfile and not os.access(cfgfile, os.R_OK):
st = os.stat(cfgfile)
print(_("Could not read %s. Re-running with sudo") % cfgfile)
try:
os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] +
sys.argv)
except Exception:
print(_('sudo failed, continuing as if nothing happened'))
print(_('Please re-run designate-manage as root.'))
sys.exit(2)
This is an interesting decision -- if the configuration file is _not_
readable by the user in question, give the executing user complete privileges
of the user that owns the unreadable file.
I'm not a fan of hiding privilege escalation / modifications in
programs -- if a user had recently used sudo and thus had the
authentication token already stored for their terminal, this 'hidden'
use of sudo may be unexpected and unwelcome, especially since it
appears that argv from the first call leaks through to the sudo call.
Is this intentional OpenStack style? Or unexpected for you guys too?
(Feel free to make this public at your convenience.)
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
