Project

General

Profile

Actions

Bug #11453

closed

run RGW as root

Added by Ken Dreyer about 9 years ago. Updated almost 6 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
firefly,hammer
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

There are rumors on the ceph-users mailing list that the ceph-radosgw service fails to start if the httpd package is not installed. This is because the init.d file attempts to start the RGW process with the "apache" UID. If a user is running civetweb, there is no reason for the httpd package to be present on the system.

We should switch the init script to use "root" as is done on Debian/Ubuntu.

Version-Release number of selected component: ceph-0.94.1

See http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-April/000257.html

Actions #1

Updated by Ken Dreyer about 9 years ago

  • Status changed from New to In Progress
  • Assignee set to Ken Dreyer
  • Backport set to firefly,hammer
Actions #2

Updated by Ken Dreyer about 9 years ago

  • Status changed from In Progress to Fix Under Review
Actions #4

Updated by Loïc Dachary about 9 years ago

  • Status changed from Fix Under Review to Pending Backport
Actions #6

Updated by Guilhem Lettron almost 9 years ago

Sorry but running RGW as root isn't a good option.
We have many problems with Chef Cookbook about radosgw user consistency between packages/distributions.

What I suggest is to run rgw with its own user/group. It add flexibility and security that people want (apache user can be added in "rgw" group).

I can add work for debian* packaging but it can break some behavior, for example we have to use a specific directory for log.
Here is a example of work we have to do in Chef Cookbook that I want to remove and push in packages: https://github.com/ceph/ceph-cookbook/commit/0845115b52d355e4c81eca149c81afafabdfb698

I'm available to discuss more about it, but it's a real and important question to answer (and using root is a quick and dirty solution).

Actions #7

Updated by Ken Dreyer almost 9 years ago

  • Regression set to No

Hi Guilhem,

You're right that running as root is not a good solution.

With the transition to civetweb, there is no longer a reason for the Apache package (httpd RPM, or apache2 DEB) to be present on the system, so the Apache UID ("apache" on RPM, "www-data" on Debian) is probably not going to be available going forward.

We really want to get away from running daemons as root in Ceph overall. There is a work-in-progress branch in GitHub called "wip-user" here: https://github.com/ceph/ceph/tree/wip-user . At the moment we are working with the distros to get static UIDs allocated for Ceph (eg. Fedora is here, https://fedorahosted.org/fpc/ticket/524, and there's an equivalent post to the SUSE and Debian lists archived somewhere). My plan is that we'll run all the Ceph daemons under this UID.

You're right that those items you linked in Chef really ought to be done in the packaging itself. My hope is that we can fix those things when wip-user gets closer to merging into the master branch.

Actions #8

Updated by Ken Dreyer almost 9 years ago

For reference, the issue that tracks running RGW (and the other daemons) as the new "ceph" unprivileged UID is #9133

Actions #9

Updated by Loïc Dachary almost 9 years ago

  • Status changed from Pending Backport to Resolved
Actions #10

Updated by Nathan Cutler almost 9 years ago

commit:a71f309 init-radosgw: run RGW as root (in firefly), commit:f30fa4a init-radosgw: run RGW as root (in hammer),

Actions #11

Updated by Tim Serong almost 9 years ago

If RGW runs as the "ceph" user, then that process could theoretically read/write raw data on the OSDs if it were possible to exploit somehow. Mightn't it be safer to leave it running as the 'www' user, but have that user created automatically when RGW is installed, if it doesn't already exist?

Actions #12

Updated by Nathan Cutler almost 9 years ago

  • Status changed from Resolved to 4
Actions #13

Updated by Nathan Cutler almost 9 years ago

Adding to what Tim said, changing this to root in firefly might cause trouble in firefly-based production installations that are already committed to apache.

Actions #14

Updated by Ken Dreyer almost 9 years ago

What sort of problems do you picture occurring when switching from an unprivileged www UID to root in firefly?

Actions #15

Updated by Sage Weil almost 6 years ago

  • Status changed from 4 to Rejected
Actions

Also available in: Atom PDF