| 1 |
> Okay, but what is this "in-depth" change that I was talking about. Well, |
| 2 |
> SELinux policies support labeled init scripts. For instance, |
| 3 |
> "slapd_initrc_exec_t" which allows the init script to run in an init |
| 4 |
> script |
| 5 |
> domain specific for slapd (splad_initrc_t). This allows for slapd-specific |
| 6 |
> allow statements (for instance PID file management) from within the init |
| 7 |
> script. |
| 8 |
> |
| 9 |
> All fine, but Gentoo doesn't use that. We run all our scripts in initrc_t |
| 10 |
> instead. Why? Because we support "integrated run_init support", which |
| 11 |
> allows |
| 12 |
> our users to just call "/etc/init.d/slapd start" instead of "run_init |
| 13 |
> /etc/init.d/slapd start". But this integrated run_init support |
| 14 |
> automatically |
| 15 |
> transitions all scripts to initrc_t (and not slapd_initrc_t). And changing |
| 16 |
> this to support the named init scripts isn't straight forward (well, I |
| 17 |
> hope |
| 18 |
> I eventually find a straight-forward method, but until now I didn't |
| 19 |
> succeed). |
| 20 |
> |
| 21 |
> Yet we will eventually need to support this, because otherwise we need to |
| 22 |
> "open" the privileges on initrc_t towards all potential services. Not only |
| 23 |
> does that require lots of work, it also brings in patches in our policy |
| 24 |
> that |
| 25 |
> upstream will never accept (and they're right not to accept it). |
| 26 |
|
| 27 |
Ok, I buy the argument. Is this a shortcoming in the old bash init, or is |
| 28 |
this a shortcoming in OpenRC? |
| 29 |
|
| 30 |
I'm starting to see a little more free time from my job and might be able |
| 31 |
to tackle some things starting in a couple of weeks. |
| 32 |
|
| 33 |
Gizmo |
Archives