Currently, Gentoo requires an administrator to re-authenticate every time they start or stop a daemon via the /etc/init.d scripts. When in the middle of system maintenance or tuning, where one is constantly starting and stopping daemons, this can quickly become annoying, if not downright cumbersome. The reference policy offers the ability to avoid this, but this capability is not currently exploited with the Gentoo policy. Investigation suggests that this may not be a trivial thing to implement. Reproducible: Always
Some quick pointers... The setting can be enabled within the reference policy by editing build.conf to say "DIRECT_INITRC = y" (default is "n"). This will add the proper attributes to sysadm_t (direct_run_init) and the exec domains of the daemons (direct_init_entry) and domains themselves (direct_init). However, it looks like when we enable this, the sysadm_r has no rights to work with initrc_exec_t (and such the current labels for /etc/init.d/* are useless). It looks like the policy wants the scripts to be labelled bin_t (no transition) so that sysadm_t can directly execute the domain_exec_t to transition to domain_t. The above analysis might be incorrect, but if not, then this isn't a change that can be made quickly: init scripts use the runscript binary, which also needs to be relabelled, and perhaps some domains need to be marked as an init_daemon_domain() to work properly. Also, it seems like all other distributions require the use of run_init (like Gentoo does - only we do this behind the scenes) so we might need to investigate why (which risks are we taking if we would support DIRECT_INITRC)?
The correct way to do this on Gentoo is to alter the pam config. The Fedora way is broken. First line of run_init's pam.d entry should do it: auth sufficient pam_rootok.so
Looks like this works when executing things with "run_init" directly (like "run_init /etc/init.d/local restart") but not when using the built-in support for run_init (like "/etc/init.d/local restart") which still seems to ask for authentication. Strace'ing shows that it does read in the /etc/pam.d/run_init file (and parses the line, and reads in pam_rootok.so). Perhaps the runscript_selinux.so library specifically asks for the password regardless of that setting?
(In reply to comment #3) > Looks like this works when executing things with "run_init" directly (like > "run_init /etc/init.d/local restart") but not when using the built-in support > for run_init (like "/etc/init.d/local restart") which still seems to ask for > authentication. > > Strace'ing shows that it does read in the /etc/pam.d/run_init file (and parses > the line, and reads in pam_rootok.so). Perhaps the runscript_selinux.so library > specifically asks for the password regardless of that setting? I don't have the behavior on my system, after placing "auth sufficient pam_rootok.so" in the first line of run_init. After this fix, when I run built-in support for run_init(like "/etc/init.d/local restart") no authorization is required(when uid=0).
Even in enforcing mode? I can't seem to reproduce that...
Going to document this as a FAQ.
Committed to CVS.
