On 01/12/2014 05:30 AM, Sven Vermeulen wrote: > On Sat, Jan 11, 2014 at 11:34:43PM -0600, Dustin C. Hatch wrote: >> My understanding is that in order to be able to control services, one >> needs to have the system_r role[1]. I don't know how to get there, though: > > You shouldn't directly mention system_r (as role) in sudo at any point as > far as I know. Either a role is granted the right to start services directly > (which is used for the services that use what I call "named init scripts") > or the role is allowed the run_init_t domain and calls it through > run_init. > That's what I thought; these were really just stabs in the dark. > In Gentoo, OpenRC calls run_init internally so you don't need to pass it on > directly when invoked through a shell. But it does require the policy change > as you mentioned (but you don't need to add it yourself, it should already > be in the Gentoo policy). > I should have mentioned that even as root, with or without pam_rootok, I can't call rc-service without run_init first. > ... > Seems that the trick from the blog post doesn't work for sudo. As far as I > can see, the transition to the sysadm_r role and sysadm_t domain work > nicely, and rc-service is a regular bin_t (so it's not about mismatching > transitions). > Again, forgot to mention that not only sudo suffers from this problem. Even logged in as root (on the console or via SSH and then newrole), I need run_init to control services. > In the mean time you can use "sudo run_init rc-service nfsmount" and grant > the user the rights for it in the sudoers file. You can also directly enter > the ROLE= and TYPE= parameters in the sudoers file so that you don't need to > pass it on directly. > In my original tests, I was using ROLE= and TYPE= in sudoers; I switched to command line arguments in order to be explicit on this message. > Wkr, > Sven Vermeulen > Thanks for your help.
-- ♫Dustin http://dustin.hatch.name/
