[Pkg-sysvinit-devel] Bug#345741: Would a restricted form of the INIT_PROG feature suffice?

[Dana How]

On 1/12/06, Dana How <danahow at gmail.com> wrote:
> On 1/12/06, Thomas Hood <jdthood at yahoo.co.uk> wrote:
> > I have an idea.  Instead of allowing an arbitrary program path to be set, we allow
> > a _suffix_ to be set.  "telinit -e INIT_SFX=foo ; telinit u" would cause init to exec
> > "/sbin/init.foo".  Now, /sbin/init.foo can be a symlink to an executable on another
> > filesystem, so this should provide the same capability as INIT_PROG; but because it
> > is done via a symlink on the same filesystem as /sbin/init, the administrator has
> > control over what init can exec.  If /sbin is on a read-only filesystem and there
> > are no /sbin/init.* then the feature is effectively disabled.
>
> This provides the admin no additional control.
> ...

On further reflection, I think we should just go down the
    telinit -e INIT_PROG:=/newpath/init
path we previously discussed (:= makes the variable get "stuck" forever).
You can do 3 things with this feature:
(a) Not use it, letting INIT_PROG be changed at will by root;
(b) Set it to the "standard" alternate init location in your boot scripts;
(c) Set it to /sbin/init in your boot scripts, making telinit -u
behave exactly as it does now.

I will send you an updated patch over the weekend,
with INIT_PROG renamed as discussed before.
Let me know what you think of it.

Thanks,
--
Dana L. How  danahow at gmail.com  +1 650 804 5991 cell