1 |
On Sat, Jan 11, 2014 at 11:34:43PM -0600, Dustin C. Hatch wrote: |
2 |
> Ansible connects to the server as an unprivileged user (typically the |
3 |
> user running it) over SSH and then executes all change commands via |
4 |
> sudo. This works for most things, like copying files, etc., but if it |
5 |
> has to restart a service after making a configuration change, it fails. |
6 |
> I am not sure how to configure SELinux policy and/or sudo to get the |
7 |
> user into the correct context to be able to restart arbitrary services. |
8 |
> I cannot use run_init because Ansible does not know how to do so. |
9 |
> |
10 |
> Here's what I've tried so far: |
11 |
[... user mapped to staff_u so it is granted staff_r/sysadm_r roles ...] |
12 |
[... pam_rootok.so used in run_init to remove root password requirement ...] |
13 |
> My understanding is that in order to be able to control services, one |
14 |
> needs to have the system_r role[1]. I don't know how to get there, though: |
15 |
> dustin@test-3238ec ~ $ sudo -r system_r rc-service nfsmount restart |
16 |
> Password: |
17 |
> sudo: unable to get default type for role system_r |
18 |
> sudo: unable to execute /sbin/rc-service: Invalid argument |
19 |
> dustin@test-3238ec ~ $ sudo -r system_r -t sysadm_t rc-service nfsmount |
20 |
> restart |
21 |
> sudo: staff_u:system_r:sysadm_t is not a valid context |
22 |
> sudo: unable to execute /sbin/rc-service: Invalid argument |
23 |
> dustin@test-3238ec ~ $ sudo -r system_r -t run_init_t rc-service |
24 |
> nfsmount restart |
25 |
> sudo: staff_u:system_r:run_init_t is not a valid context |
26 |
> sudo: unable to execute /sbin/rc-service: Invalid argument |
27 |
|
28 |
You shouldn't directly mention system_r (as role) in sudo at any point as |
29 |
far as I know. Either a role is granted the right to start services directly |
30 |
(which is used for the services that use what I call "named init scripts") |
31 |
or the role is allowed the run_init_t domain and calls it through |
32 |
run_init. |
33 |
|
34 |
In Gentoo, OpenRC calls run_init internally so you don't need to pass it on |
35 |
directly when invoked through a shell. But it does require the policy change |
36 |
as you mentioned (but you don't need to add it yourself, it should already |
37 |
be in the Gentoo policy). |
38 |
|
39 |
> I tried a policy change that should allow OpenRC to make the transition |
40 |
> for me[2] but it did not work: |
41 |
[...] |
42 |
> dustin@test-3238ec ~ $ sudo -r sysadm_r -t sysadm_t rc-service nfsmount |
43 |
> restart |
44 |
> Password: |
45 |
> Authenticating root. |
46 |
> Cannot find your entry in the shadow passwd file. |
47 |
> |
48 |
> I'm not sure where to go from here. Any help would be appreciated. |
49 |
|
50 |
I'll look into it (it's reproduceable). |
51 |
|
52 |
Seems that the trick from the blog post doesn't work for sudo. As far as I |
53 |
can see, the transition to the sysadm_r role and sysadm_t domain work |
54 |
nicely, and rc-service is a regular bin_t (so it's not about mismatching |
55 |
transitions). |
56 |
|
57 |
In the mean time you can use "sudo run_init rc-service nfsmount" and grant |
58 |
the user the rights for it in the sudoers file. You can also directly enter |
59 |
the ROLE= and TYPE= parameters in the sudoers file so that you don't need to |
60 |
pass it on directly. |
61 |
|
62 |
Wkr, |
63 |
Sven Vermeulen |