[Pkg-sysvinit-devel] Bug#345741: Would a restricted form of the
INIT_PROG feature suffice?
danahow at gmail.com
Thu Jan 12 18:09:43 UTC 2006
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.
Dana L. How danahow at gmail.com +1 650 804 5991 cell
More information about the Pkg-sysvinit-devel