yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #54829
[Bug 1611171] Re: re-runs self via sudo
Apparantly, this isn't unique to Designate either:
http://git.openstack.org/cgit/openstack/cinder/tree/cinder/cmd/manage.py
http://git.openstack.org/cgit/openstack/nova/tree/nova/cmd/manage.py
** Also affects: nova
Importance: Undecided
Status: New
** Also affects: cinder
Importance: Undecided
Status: New
** Also affects: ec2-api
Importance: Undecided
Status: New
** Also affects: gce-api
Importance: Undecided
Status: New
** Also affects: manila
Importance: Undecided
Status: New
** Also affects: masakari
Importance: Undecided
Status: New
** Also affects: rally
Importance: Undecided
Status: New
--
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:
New
Status in Designate:
In Progress
Status in ec2-api:
New
Status in gce-api:
New
Status in Manila:
New
Status in masakari:
New
Status in OpenStack Compute (nova):
New
Status in Rally:
New
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