Advices for an su transition
On Sun, Nov 06, 2005 at 11:14:39PM +0100, Nicolas François wrote:
> We would now like to get rid of this bug. What do you recommend:
> * keep a Debian specific implementation and tag this bug wontfix
> * reapply the patch to fix this bug, and report bugs on the packages that
> uses this "feature"
I've not seen a strong opposition to the second choice.
We now need some advices to perform this transition.
Junichi proposed to keep the current behavior when an environment variable
is set (I would prefer something different from POSIXLY_CORRECT). The
support for this environment variable could then be dropped after Etch.
The change will have to be announced (here and in NEWS) and documented.
(Basically, -c's argument is a command executed in the shell, other
arguments given after '--' are provided to the shell, not to the command)
Another step is to find which packages won't work with this change, get
them fixed and upload a new login which conflicts with their previous
I think such softwares won't run with upstream's su (i.e. at least Redhat
and Gentoo), GNU's su (coreutils), FreeBSD's su (and OpenSolaris' su).
So I hope only Debian specific packages or Debian maintainers' scripts
will be affected.
At this time we are aware of:
* pbuilder (not true anymore)
dchroot synopsis is: dchroot [OPTION...] [COMMAND]
it passes its arguments to su. -c is not provided.
COMMAND needs to be a single argument.
There are no dependencies on login, so I don't see anything else than a
grep on the 2 letters "su" (\<su\> may help).
IIRC people from debian-audit have some tools to perform such grep on the
source package with some heuristics to extract and patch the sources
(dpatch, cdbs, ...), and ignore the documentation files (e.g. "su" is a
common word in spanish).
I have no idea of the size of such grep output.
Does anybody have another idea?