[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

* Luk Claes [2011-04-06 07:20 +0200]:
> On 04/06/2011 01:55 AM, Carsten Hey wrote:
> > Guaranteeing that /bin/sh exists and is functional during debootstrap,
> > even before any maintainer script has been run, could be archived if
> > every system shell would provide /bin/sh pointing to itself.  To avoid
> > file conflicts, all but the one whose preinst is run first (finding
> > a clever way to detect this shouldn't be that hard) could divert their
> > /bin/sh to /bin/sh.$SHELL.  When update-shell (or whatever it's name
> > would be) finally takes over managing /bin/sh, it could divert the
> > remaining /bin/sh away and replace it with a symlink not known to the
> > packaging system.
> That unfortunately does not work as diversions are only meant to be used
> when 2 packages provide the same file.

Actually, this impossible use of dpkg-divert was intended to be a way to
work around the missing (or unwanted?) hook support in deboostrap and
cdebootstrap.  Packages in base could use these hooks to set up a part
of what is currently done in /usr/share/debootstrap/scripts/.

Without such hooks, adding /bin/sh could still be done in debootstrap
and cdebootstrap.

> One of the problems being what to do when you remove one of the shells
> (for instance the one providing /bin/sh)...

ksh's prerm script would call "update-shell remove /bin/ksh93".  If
/bin/sh would point to ksh93, update-shell would change /bin/sh to point
to the registered system-shell with the highest priority.

System shells would (de)register themselves by calling add-system-shell
in postinst and remove-system-shell in prerm.  'system-shell' would also
be a virtual package provided by bash, dash and so on.  Although I don't
think this would be a problem, using /bin/$SHELL in the shebang of
postinst and prerm could prevent possible problems if /bin/sh changes
whilst these scripts are running.

* Simon McVittie [2011-04-06 11:22 +0100]:
> > Passing a shell to it that is not included in /etc/shells could lead
> > to failing of this tool, unless --force is used.
> Not everything in /etc/shells is POSIXy enough to be /bin/sh.

This was not meat as whitelist but as "inverse blacklist" (everything
not in it is most probable not a adequate /bin/sh).  Anyway, this was
a bad idea.


Reply to: