From: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
To: Sage Weil <sweil@redhat.com>, Ken Dreyer <kdreyer@redhat.com>
Cc: ceph-devel@vger.kernel.org, ceph-maintainers@ceph.com
Subject: Re: running daemons as user/group ceph
Date: Sat, 25 Apr 2015 09:35:14 +0200 [thread overview]
Message-ID: <553B43B2.2070102@bisect.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1504241630050.5458@cobra.newdream.net>
Am 25.04.2015 um 01:34 schrieb Sage Weil:
> On Fri, 24 Apr 2015, Ken Dreyer wrote:
>> Oh, my bad, sorry I missed that part of the pull request! Looks good to me.
>
> Still missing ceph.spec file changes, if you're up for it. :)
I can change the spec files, but do we have finally some user/group IDs
for RHEL/Fedora and SLE/openSUSE?
> I'm working on the chown piece, but I'm not sure what to do about the
> journal device (if it is a device). We can either
>
> - add ceph to the 'disk' group. This means it can scribble on any device
> in the system, which seems less than ideal.
I wouldn't do that. Especially from the security perspective.
> - chown the journal device to ceph when the daemon is started. This
> means the user can only scribble on other ceph devices, which seems about
> right. But I'm not sure what the implications of chowning random devices
> like /dev/sdc2 to ceph are.
Not sure if this is what we want or that this is the "usual" way to
handle these issues.
> - do something tricky where we open the block device on startup before
> doing the setuid, and reuse that file handle later. This likely screws up
> all kinds layering because we want the privs to drop very eary (before we
> start opening log files, for example) and only the journal code knows what
> mode to open the file as. Any solution here will be kind of kludgey, I
> think.
The log files are not the issue here I guess since you can set the
correct permissions outside of the daemons. If an OSD need to open a
device it would be appropriate to open the device as root before
dropping the privileges. The code shouldn't be that complicated we did
such things e.g. in hald before.
Another issue: there is the --enable-root-make-check configure option. I
didn't take a look at the code yet, but does anybody know if these tests
refer to something that needs root privileges within the daemons or is
it due to testing something (like e.g. mount rbd's)?
Danny
next prev parent reply other threads:[~2015-04-25 7:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 17:37 running daemons as user/group ceph Sage Weil
2015-04-24 20:16 ` Danny Al-Gaaf
2015-04-24 20:52 ` Sage Weil
2015-04-24 21:05 ` Robert LeBlanc
2015-04-25 7:22 ` Danny Al-Gaaf
2015-04-24 21:04 ` Ken Dreyer
2015-04-24 21:13 ` Sage Weil
2015-04-24 22:29 ` [Ceph-maintainers] " Sage Weil
2015-04-24 22:30 ` Ken Dreyer
2015-04-24 23:34 ` Sage Weil
2015-04-25 7:35 ` Danny Al-Gaaf [this message]
2015-04-25 17:26 ` Sage Weil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553B43B2.2070102@bisect.de \
--to=danny.al-gaaf@bisect.de \
--cc=ceph-devel@vger.kernel.org \
--cc=ceph-maintainers@ceph.com \
--cc=kdreyer@redhat.com \
--cc=sweil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.