Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Bastian Blank wa...@debian.org writes: On Sun, Apr 10, 2011 at 11:58:09AM +0200, Goswin von Brederlow wrote: Bastian Blank wa...@debian.org writes: On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: Here I think we can go one of two ways: 2) bootstrap scripts are only executed after the owners (Pre-)Depends have been unpacked. This would allow base-files to setup the links based on available packages and some internal preference list. In this scenario I think base-files should set up /bin/sh and /usr/bin/awk and gain a Pre-Depends: system-shell. This will work now. But needs a lot of work to move the system-shell name later to another package. Why? To move it the new package would Pre-Depend on system-shell, gain a bootstrap script and possibly conflict with older base-files. I thought about moving the name system-shell, aka the provides. This proposal means that base-files needs to know about all packages that provides the name. Then we can drop the provides alltogether. Bastian Indeed. So option 1 is probably the way to go. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjtnhb71.fsf@frosties.localnet
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Adam Borowski kilob...@angband.pl writes: On Sat, Apr 09, 2011 at 11:42:12PM +0200, Bastian Blank wrote: On Fri, Apr 08, 2011 at 06:52:41PM +0200, Bastian Blank wrote: We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script called bootstrap in its control.tar. - It must be called outside of the new root, so it can assume that it can execute some essential commands. What about making that essential commands mean present on any popular POSIXy environment? Explicitely including busybox. Debootstrap is something you're likely to run from Red Hat, etc, setups, so assuming Debian tools are present would be a regression. That certainly is the intention. Something like debconf or dpkg is not essential in this context. Thinks like test and ln are ment here. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o64khxg.fsf@frosties.localnet
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Sun, Apr 10, 2011 at 11:58:09AM +0200, Goswin von Brederlow wrote: Bastian Blank wa...@debian.org writes: On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: Here I think we can go one of two ways: 2) bootstrap scripts are only executed after the owners (Pre-)Depends have been unpacked. This would allow base-files to setup the links based on available packages and some internal preference list. In this scenario I think base-files should set up /bin/sh and /usr/bin/awk and gain a Pre-Depends: system-shell. This will work now. But needs a lot of work to move the system-shell name later to another package. Why? To move it the new package would Pre-Depend on system-shell, gain a bootstrap script and possibly conflict with older base-files. I thought about moving the name system-shell, aka the provides. This proposal means that base-files needs to know about all packages that provides the name. Then we can drop the provides alltogether. Bastian -- Beam me up, Scotty! It ate my phaser! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411144819.ga19...@wavehammer.waldi.eu.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: - The rules for essential packages must remain fulfilled on upgrades without this script being executed. The bootstrap script is never executed if the system was installed from a version predating the bootstrap script in the package. This is already clear in the policy. - It must be called before any maintainer script of any package other than the bootstrap script is called. Okay. - It must not execute other scripts or executables in the new root. Okay, that is enough. For now two packages will get such a script: I missed dpkg. At least cdebootstrap still inits files in /var/lib/dpkg. Here I think we can go one of two ways: 2) bootstrap scripts are only executed after the owners (Pre-)Depends have been unpacked. This would allow base-files to setup the links based on available packages and some internal preference list. In this scenario I think base-files should set up /bin/sh and /usr/bin/awk and gain a Pre-Depends: system-shell. This will work now. But needs a lot of work to move the system-shell name later to another package. Bastian -- Oh, that sound of male ego. You travel halfway across the galaxy and it's still the same song. -- Eve McHuron, Mudd's Women, stardate 1330.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110410075720.ga28...@wavehammer.waldi.eu.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Bastian Blank wa...@debian.org writes: On Sun, Apr 10, 2011 at 02:18:49AM +0200, Goswin von Brederlow wrote: Here I think we can go one of two ways: 2) bootstrap scripts are only executed after the owners (Pre-)Depends have been unpacked. This would allow base-files to setup the links based on available packages and some internal preference list. In this scenario I think base-files should set up /bin/sh and /usr/bin/awk and gain a Pre-Depends: system-shell. This will work now. But needs a lot of work to move the system-shell name later to another package. Bastian Why? To move it the new package would Pre-Depend on system-shell, gain a bootstrap script and possibly conflict with older base-files. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei5azavi.fsf@frosties.localnet
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Sat, Apr 09, 2011 at 11:42:12PM +0200, Bastian Blank wrote: On Fri, Apr 08, 2011 at 06:52:41PM +0200, Bastian Blank wrote: We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script called bootstrap in its control.tar. - It must be called outside of the new root, so it can assume that it can execute some essential commands. What about making that essential commands mean present on any popular POSIXy environment? Explicitely including busybox. Debootstrap is something you're likely to run from Red Hat, etc, setups, so assuming Debian tools are present would be a regression. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Fri, Apr 08, 2011 at 06:52:41PM +0200, Bastian Blank wrote: We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script called bootstrap in its control.tar. - This script must be executable and use /bin/sh as interpreter. - The rules for essential packages must be fulfilled after this script was executed. - It should be called by the bootstrap process after the initial unpack of the owning package or all packages in the essential set. - It must be called outside of the new root, so it can assume that it can execute some essential commands. - It must not access other scripts or executables in the new root. For now two packages will get such a script: - dash (setup of /bin/sh) - base-files (setup of /usr/bin/awk) The bootstrap process may work this: - The data.tar of every package in the essential set is unpacked. - The bootstrap scripts from the control.tar of every package in the essential set is extracted and executed. Bastian -- Prepare for tomorrow -- get ready. -- Edith Keeler, The City On the Edge of Forever, stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409214212.gc21...@wavehammer.waldi.eu.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Sat, Apr 09, 2011 at 11:42:12PM +0200, Bastian Blank wrote: For now two packages will get such a script: - base-files (setup of /usr/bin/awk) Err. I meant mawk. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409215736.ga23...@wavehammer.waldi.eu.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Bastian Blank wa...@debian.org writes: On Fri, Apr 08, 2011 at 06:52:41PM +0200, Bastian Blank wrote: We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script called bootstrap in its control.tar. - This script must be executable and use /bin/sh as interpreter. - The rules for essential packages must be fulfilled after this script was executed. - The rules for essential packages must remain fulfilled on upgrades without this script being executed. The bootstrap script is never executed if the system was installed from a version predating the bootstrap script in the package. - It should be called by the bootstrap process after the initial unpack of the owning package or all packages in the essential set. - It must be called before any maintainer script of any package other than the bootstrap script is called. - It must be called outside of the new root, so it can assume that it can execute some essential commands. - It must not access other scripts or executables in the new root. - It must not execute other scripts or executables in the new root. - It must not rely on the presence of any files or directories outside the contents of the owning package. Note: Unpacking and calling the script can be any order without regards to dependencies. It can access files or directories from the owning package as long as it doesn't execute anything. Unless we want the essential system-shell package to setup /bin/sh and base-files to setup /usr/bin/awk. Then (Pre-)Depends must be at least unpacked. See below. - Scripts are to be kept to a minimum and simple to be run by even not fully POSIX compliant /bin/sh. - Scripts must not fail if a competing package was bootstraped first. E.g. mawk must not fail if gawk is already in palce. For now two packages will get such a script: - dash (setup of /bin/sh) - base-files (setup of /usr/bin/awk) Here I think we can go one of two ways: 1) The (pseudo-)essential packages providing will setup the link themself. For this dash, bash, mawk and gawk would each have a bootstrap script. Whichever gets executed first sets up the required link. The result would be random. Optionally the default provider could overwrite the link if it exists while all others only set it if missing. This would give some preference to the result but still allow choice if the default provider is explicitly excluded in the bootstrap. 2) bootstrap scripts are only executed after the owners (Pre-)Depends have been unpacked. This would allow base-files to setup the links based on available packages and some internal preference list. In this scenario I think base-files should set up /bin/sh and /usr/bin/awk and gain a Pre-Depends: system-shell. The result would still be random and potentially more so that option 1. bash + base-files might be unpacked, bootstraped and only then dash, which would normaly be the deafult, is unpacked. Here dash could not be made to override bash as inital /bin/sh. The bootstrap process may work this: - The data.tar of every package in the essential set is unpacked. - The bootstrap scripts from the control.tar of every package in the essential set is extracted and executed. + pseudo-essential If we go ahead with this I would recommend that support for bootstrap scripts will be backported to bootstrap tools in squeeze in some point release and that only after wheezy is released bootstrap tools will be required to execute the bootstrap script. That way even old-stable (except early point releases) will be able to bootstrap unstable. Bastian MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v1buffa.fsf@frosties.localnet
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Thu, Apr 07, 2011 at 12:16:02PM +0200, Goswin von Brederlow wrote: Carsten Hey cars...@debian.org writes: 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 How would that work with (c)debootstrap/multistrap when creating a chroot for a foreign architecture? No maintainer script will be run in those cases nor can they be run in general. We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script. - This must be a /bin/sh script. - It may be called after the initial unpack of the bootstrap process. - It must be called outside of the new root, so it can assume that it can execute some essential commands. The other solution is to hardcode the setup like the awk link. Some package needs to initially ship a /bin/sh binary or symlink, which I would think dash should do (being the default sh). And the registering in postinst could then later replace this with the proper mechanism (which would still just be a symlink to dash by default I guess). This means that we will get a diversion just to please the bootstrap. Bastian -- Death, when unnecessary, is a tragic thing. -- Flint, Requiem for Methuselah, stardate 5843.7 signature.asc Description: Digital signature
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Bastian Blank wa...@debian.org writes: On Thu, Apr 07, 2011 at 12:16:02PM +0200, Goswin von Brederlow wrote: Carsten Hey cars...@debian.org writes: 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 How would that work with (c)debootstrap/multistrap when creating a chroot for a foreign architecture? No maintainer script will be run in those cases nor can they be run in general. We have the same problem with awk since ages. We should fix both problems together. Therefor I propose the following: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script. - This must be a /bin/sh script. - It may be called after the initial unpack of the bootstrap process. - It must be called outside of the new root, so it can assume that it can execute some essential commands. You then need a way to pass the location of the chroot to the new maintainer script. So a slightly different (or extended) interface compare to pre/posrinst/rm. But this might do as a general solution for both /bin/sh and /usr/bin/awk. Both could have a (lets call it) DEBIAN/bootstrap scrtipt. The other solution is to hardcode the setup like the awk link. Some package needs to initially ship a /bin/sh binary or symlink, which I would think dash should do (being the default sh). And the registering in postinst could then later replace this with the proper mechanism (which would still just be a symlink to dash by default I guess). This means that we will get a diversion just to please the bootstrap. Bastian Indeed. But no pre-bootstrap script neccessary. Is there a debootstrap for windows (or similar) that would have problems executing a /bin/sh script? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4f4k5ur.fsf@frosties.localnet
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Fri, Apr 08, 2011 at 07:31:08PM +0200, Goswin von Brederlow wrote: Bastian Blank wa...@debian.org writes: - An essential or pseudo-essential (dependency or pre-dependency from an essential package) may include a new maintainer script. - This must be a /bin/sh script. - It may be called after the initial unpack of the bootstrap process. - It must be called outside of the new root, so it can assume that it can execute some essential commands. You then need a way to pass the location of the chroot to the new maintainer script. So a slightly different (or extended) interface compare to pre/posrinst/rm. But this might do as a general solution for both /bin/sh and /usr/bin/awk. Both could have a (lets call it) DEBIAN/bootstrap scrtipt. Well, we could just use the working directory. Is there a debootstrap for windows (or similar) that would have problems executing a /bin/sh script? No, there is not. Also Windows is not able to write filesystems suitable for a Debian root filesystem. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110408180014.ga31...@wavehammer.waldi.eu.org
Re: Moving bash from essential/required to important?
On Wed, 06 Apr 2011 16:37:28 +0100, Lars Wirzenius l...@liw.fi wrote: ... Obviously, checkbashisms is not infallible, so the numbers may well be off. If I remove all the not bash scripts from bash2.list, I get a much shorter file: http://files.liw.fi/temp/bash2-isbash.list Summary: 1775 files 621 packages ... Obviously, doing these changes earlier rather than later in the release cycle would be good, if they are to be done at all. Opinions? I think you've demonstrated exactly why we should do this -- at present, since bash is essential, it would seem that many people have decided that it's easiest to just use /bin/bash for their scripts, regardless of whether they need it or not, which is fine on a full blown Debian system but creates a lot of unnecessary work for EmDebian folks. It wouldn't surprise me if the need to add a bash dependency would provoke many of the developers of the packages in question to reexamine those scripts, realise that in many cases they could be trivially POSIX-ised, and so reduce that number further. That'll not happen if we don't make bash non-essential. On the other hand, my perspective is that of a crusty old git who had to port stuff to all sorts of not-quite-POSIX systems for years, so I may just be having a youngsters need to be taught proper discipline moment ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpAyDXO3LmrE.pgp Description: PGP signature
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
Carsten Hey cars...@debian.org writes: 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 How would that work with (c)debootstrap/multistrap when creating a chroot for a foreign architecture? No maintainer script will be run in those cases nor can they be run in general. Some package needs to initially ship a /bin/sh binary or symlink, which I would think dash should do (being the default sh). And the registering in postinst could then later replace this with the proper mechanism (which would still just be a symlink to dash by default I guess). 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. In postinst and prerem there is no problem in using /bin/$SHELL since the shell is already/still present. But what about preinst and postrm? We can probably assume there will allways be one system shell present so /bin/sh for postrm is fine. But for preinst we are back to the above problem. When bootstraping no postinst of any system shell has yet run so there is no /bin/sh configure. Yet we still need one. Even using an elf binary as preinst to create the initial /bin/sh link would be ugly because then bootstraping tools (second stage) need the special knowledge to run that first. Which brings us back to the need for some (dash :) package to ship an initial /bin/sh before the proper (de)registering mechanism takes over. Please keep that in mind when designing it. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp0igye5.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
On ke, 2011-04-06 at 16:37 +0100, Lars Wirzenius wrote: Obviously, doing these changes earlier rather than later in the release cycle would be good, if they are to be done at all. OK, so assuming anything is to be done about this at all, here's what I suggest: * add a lintian test that detects scripts that are needlessly #!/bin/bash according to checkbashisms; the test can't be extremely reliable, but would probably be good enough * get project consensus on whether bash should remain essential or not (so far my reading of this thread indicates it is inconclusive); if there is no consensus, stop here * add lintian test for packages that contain bash scripts but don't declare a dependency on bash * inform the project of bash losing essentialness (mail to d-d-a) * do a mass bug filing on all packages that a) contain bash scripts that checkbashisms confirms have bashisms b) do not depend on bash * do another mass bug filing on all packages that contain bash scripts that checkbashisms does not think contain any bashisms * wait some months for package maintainers to fix their packages * NMU all packages that have not been fixed Opinions? I assume it would be the release team's decision about bash essentialness? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302187274.2441.34.ca...@havelock.liw.fi
Re: Moving bash from essential/required to important?
Hi Lars! On Thu, 07 Apr 2011 16:41:14 +0200, Lars Wirzenius wrote: On ke, 2011-04-06 at 16:37 +0100, Lars Wirzenius wrote: Obviously, doing these changes earlier rather than later in the release cycle would be good, if they are to be done at all. OK, so assuming anything is to be done about this at all, here's what I suggest: * add a lintian test that detects scripts that are needlessly #!/bin/bash according to checkbashisms; the test can't be extremely reliable, but would probably be good enough * get project consensus on whether bash should remain essential or not (so far my reading of this thread indicates it is inconclusive); if there is no consensus, stop here Given how far you have already gone with the analysis, I would stop here in no case, especially considering... * do another mass bug filing on all packages that contain bash scripts that checkbashisms does not think contain any bashisms ...there is no point using #!/bin/bash when the script is POSIX-compliant, since the default #!/bin/sh on Debian (dash) is faster than bash. Thx, bye, Gismo / Luca pgpPp4TJXZe7R.pgp Description: PGP signature
Re: Moving bash from essential/required to important?
]] Luca Capello Hi, |* do another mass bug filing on all packages that contain bash | scripts that checkbashisms does not think contain any bashisms | | ...there is no point using #!/bin/bash when the script is | POSIX-compliant, since the default #!/bin/sh on Debian (dash) is faster | than bash. There might very well be, such as upstream shipping scripts that are written to work on both solaris and linux. (Solaris's /bin/sh isn't POSIX.) Changing this to deviate from upstream would be silly, IMO. Also, lots of scripts aren't speed-sensitive and people don't want to think about whether something uses bashisms or not, so they use «#! /bin/bash» to rather be safe than sorry. (I think the whole «make bash optional» thing is pointless and a waste of developer resources. It makes embedded developers's lives slightly easier at the cost of lots of manual checking, time I think would be better spent fixing real bugs.) Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc4ivu9c@qurzaw.varnish-software.com
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On Wed, 06 Apr 2011 at 01:55:20 +0200, Carsten Hey wrote: It would also need to assure that whilst it is running /bin/sh is always functional. 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. The *csh family aren't Bourne shells, and while zsh is a very nice Bourne-ish interactive shell, in its default configuration it isn't POSIX-compliant. smcv (a zsh user) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110406102207.ga18...@reptile.pseudorandom.co.uk
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On 2011-04-06 11:22:07 +0100, Simon McVittie wrote: Not everything in /etc/shells is POSIXy enough to be /bin/sh. The *csh family aren't Bourne shells, and while zsh is a very nice Bourne-ish interactive shell, in its default configuration it isn't POSIX-compliant. When invoked as sh, zsh should be in a POSIX-compliant configuration. The main problem is that AFAIK, it still has bugs... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110406115509.gb13...@prunille.vinc17.org
Re: Moving bash from essential/required to important?
On ti, 2011-04-05 at 08:52 +0100, Lars Wirzenius wrote: I'm re-running the scripts, which will probably take a few hours, and will report results when they're done. If you notice any problems with the scripts, please tell me ASAP. The new scripts look also in maintainer scripts. New results: http://files.liw.fi/temp/bash2.list Summary: 4450 files 973 packages I further ran checkbashisms on every file in bash2.list, and classified files accordingly to the exit code: exit code 0 means it's not a bash script. Result: http://files.liw.fi/temp/reallybash.list Summary: 1787 files classified as bash scripts 2663 not bash scripts Obviously, checkbashisms is not infallible, so the numbers may well be off. If I remove all the not bash scripts from bash2.list, I get a much shorter file: http://files.liw.fi/temp/bash2-isbash.list Summary: 1775 files 621 packages Assuming I didn't do anything stupid in these scripts or in counting the results, it looks like it's a reasonably small set of packages that would need to add a bash dependency. However, that would require all the #!/bin/bash scripts that don't actually need to be bash to be changed (and tested etc). Obviously, doing these changes earlier rather than later in the release cycle would be good, if they are to be done at all. Opinions? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302104248.2627.88.ca...@havelock.liw.fi
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: Hi bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I definitely like this idea. While I wouldn't ever uninstall bash on my own laptop/server/whatever (unless someone comes along with a nice replacement), dropping it on embedded devices makes a lot of sense. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011040628.gb9...@suiko.acc.umu.se
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. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407000526.ga27...@furrball.stateful.de
Re: Moving bash from essential/required to important?
On Monday 04 April 2011 18.04:20 Luk Claes wrote: The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. Do you have any kind of estimate how many peopl would need to depend on bash? If it's a few hundred: no problem, why not tackle this as a wheezy release goal. If it's 4000, don't bother. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part.
Re: Moving bash from essential/required to important?
Steve Langasek vor...@debian.org writes: On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I think we should avoid doing this for quite a different reason from the other responders. Consider that 'base-passwd' and 'login' are also part of the essential set. Why? Because being able to log in as root is part of the minimal set of functionality that must be available and usable on the system at all times. So if we drop bash from essential, how do we guarantee that root can log in? Do we set root's default shell to /bin/sh instead? I don't think anyone would be happy with that except those people who already change it to zsh anyway. :-) So why not provide a system shell and a login shell? Both could be provided by dash or bash (or other shells that proove to be compatible like zsh as login shell). But the system shell would default to dash while the login shell defaults to bash. Both system shell and login shell would be essential but neither dash nor bash needs to be. Like awk being essential but neither mawk nor gawk is. Imediate use cases would be twofold: 1) embedded systems that can suffer through dash as login shell 2) users that want zsh instead of bash as login shell anyway If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. So lets start with saying that things that use bash need to depend on it so we will have the option to make bash not essential in the future. This will take some time to do and a release cycle. Worst case we get a bunch of depends on bash that aren't needed. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqp1nrgf.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
Lars Wirzenius l...@liw.fi writes: * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. I've beend thinking about this a while back when I had a package fail due to missing Depends for some shell script. So I would even take it a step further. dpkg-shlibsdebs finds all depends needed for dynamic libraries automatically. Why not find all depends needed for shell scripts automatically too? 1) check shebang for the needed shell 2) parse shell script and extract all executables being called 3) lookup packages for for binaries 4) remove essential packages 5) set substvar So if you have a script like #!/usr/bin/zsh if [ grep-dctrl foo bar ]; then echo buzz fi you would get a dependency on zsh and dctrl-tools. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lizpnr3v.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
Luk Claes l...@debian.org writes: What about Roger's suggestion to have the root account passwordless and locked with sudo access? Are there other drawbacks to that proposal (is booting in single user mode covered for instance?)? Then a fsck failure won't give you a shell because you can't input the root password. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbadnr0i.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
Carsten Hey cars...@debian.org writes: Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. I have no problem with bash being build-essential to avoid needing Build-Depends: bash. This is really a seperate issue from bash being essential. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3l1nqrz.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh rle...@codelibre.net wrote: On Mon, Apr 04, 2011 at 05:59:51PM +, Clint Adams wrote: On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. Likewise. Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] I really really disagree... In case of disaster running under root is essential. Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktik_bddvqqrkz8ke_8mh_tcus_+...@mail.gmail.com
Re: Moving bash from essential/required to important?
On ma, 2011-04-04 at 20:32 +0100, Lars Wirzenius wrote: I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. I made some changes to the scripts to the scripts: * unpack-debian-binaries now handles multiple binary packages from he same source package; previously it would use only the data.tar.* from one of the binary packages, and this is why gzip's scripts in /bin didn't show up (thanks Carsten) * isbash now looks for a hashbang that includes bash at all, which should cover things like #!/usr/bin/env bash and #!/bin/bash -e (raised in IRC) * find-bash-scripts now also searches through the contents of control.tar.* (thanks, Luk) New versions of the scripts attached. I'm re-running the scripts, which will probably take a few hours, and will report results when they're done. If you notice any problems with the scripts, please tell me ASAP. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ find-bash-scripts Description: application/shellscript isbash Description: application/shellscript unpack-debian-binaries Description: application/shellscript
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 09:36:14AM +0200, Bastien ROUCARIES wrote: On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh rle...@codelibre.net wrote: On Mon, Apr 04, 2011 at 05:59:51PM +, Clint Adams wrote: On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. Likewise. Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] I really really disagree... In case of disaster running under root is essential. Of course. This change would in no way prevent running under root in case of problems. If the root account is locked and has no password, you get dropped into a root shell on the console like normal, but the password prompt is skipped, if fatal errors are encountered at startup. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
Goswin von Brederlow goswin-...@web.de writes: Lars Wirzenius l...@liw.fi writes: * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. I've beend thinking about this a while back when I had a package fail due to missing Depends for some shell script. So I would even take it a step further. dpkg-shlibsdebs finds all depends needed for dynamic libraries automatically. That information is quite neatly and unambigously encoded in the binaries, making extraction of the information both (relatively) easy and reliable. With shell scripts, this is not the case, see below. Why not find all depends needed for shell scripts automatically too? 1) check shebang for the needed shell Seems like a reasonable thing to do. 2) parse shell script and extract all executables being called You can't generally do that without executing the shell script, and even then you'd miss out on stuff that's not invoked due to conditionals. It's certainly possible to get a subset of executables used by parsing, but it's bound to be an unreliable heuristic. Additionally, adding a shell script parser would probably add quite a bunch of code. I don't see the point of doing that when you'd have to check the result anyway, since the information is unreliable -- and when you need to do that, you might as well specify the dependencies manually. 3) lookup packages for for binaries 4) remove essential packages 5) set substvar So if you have a script like #!/usr/bin/zsh if [ grep-dctrl foo bar ]; then echo buzz fi you would get a dependency on zsh and dctrl-tools. One more point: you'd have to write a parser to understand zsh syntax to do that in general. Regards, Rotty -- Andreas Rottmann -- http://rotty.yi.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbadyt3j@gmx.at
Re: Moving bash from essential/required to important?
* Guillem Jover [2011-04-05 06:19 +0200]: On Tue, 2011-04-05 at 01:08:19 +0100, Ben Hutchings wrote: This appears to open up any accounts that have been deliberately disabled by setting their shell to a nonexistent path. I know that's a dumb way to disable an account, but that doesn't make this any less of a security hole. How about checking for the configured shell in /etc/shells before enabling the fallback? Ah good catch! Done with the attached patch. mksh.prerm contains: remove|upgrade|deconfigure) update-alternatives --remove ksh /bin/mksh update-alternatives --remove ksh /bin/mksh-static remove-shell /bin/mksh remove-shell /bin/mksh-static bash.postrm contains: remove|purge|disappear) if which remove-shell /dev/null [ -f /etc/shells ]; then remove-shell /bin/bash remove-shell /bin/rbash fi ... so they are missing from /etc/shells after they have been removed. Alternatives include a hardcoded list instead of relying on /etc/shells or an additional file that contains all shells that were ever part of /etc/shells. prerm could also fail it the shell is set as root's (or any, otherwise setups using sudo instead of root might break) login shell. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405090235.gb10...@furrball.stateful.de
Re: Moving bash from essential/required to important?
On 05/04/11 04:52, Russ Allbery wrote: dash doesn't support $LINENO, which is why it's not detected by Autoconf. The reason why it doesn't support $LINENO (it's intentional; we had a patch to add it that was then removed) is that the configure.ac files of many, many packages contain bashisms that dash doesn't support. If $LINENO support is present in dash, Autoconf considers dash sufficiently POSIX to use as the configure shell, and then all those packages FTBFS. We could do as with binutils-gold. Report bugs with severity important now, make it a release goal to make dash fully POSIX-compliant (including $LINENO support), and if the bug count gets low enough in time, do the switch, and otherwise, do it at the beginning of the next cycle (assuming we've fixed enough bugs). Cheers, Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9ad900.9010...@debian.org
Re: Moving bash from essential/required to important?
* Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Fix #428189, either by adapting the policy to reality or vice versa (depending on the maintainers decision) as prerequisite to fix the next point without breaking things afterwards. This doesn't appear to be relevant to moving bash out of Essential. dash, which would still be Essential (no one is proposing removing /bin/sh from Essential!), also has printf as a shell builtin. It would be good to resolve this bug in its own right, but it appears to be orthogonal to whether bash is Essential. This is only relevant because the next point is in my opinion relevant and fixing the next one might lead the next best maintainer of a policy complying shell to enable this shell to become /bin/sh. If there is no correctly documented consensus (in the policy) about what a shell needs to provide to let scripts rely on printf (and theoretically also [ and test) being available, this could lead to non-bootable systems. * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. We are using different hacks to manage /bin/sh since about five years. Making things even more hackish or complicated, e.g. by not being able to rely on dash or bash to be installed and/or moving /bin/sh around, would increase the number of corner cases to be caught and thus make implementing a clean solution even more hard. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405101233.gc10...@furrball.stateful.de
Re: Moving bash from essential/required to important?
Luk Claes l...@debian.org (04/04/2011): The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) KiBi. signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405170908.gx3...@radis.liafa.jussieu.fr
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 07:09:08PM +0200, Julien Cristau wrote: On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? They probably all want to do this. But while removing dash and coreutils from Essential is probably not practical at present, removing just bash would still go a long way to help since that's at least /one/ of these packages for which we would have a contract saying Debian supports removing it. If the package gets pulled into your environment as a dependency, you know what dependency to fix. If the package is pulled in because it's Essential and you want to remove it, you have to constantly inspect the system to make sure nothing is using it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Tue, 5 Apr 2011 19:09:08 +0200, Julien Cristau jcris...@debian.org wrote: On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? And your point is? If both dash and busybox provide posix shell, and removing bash from essential highlights those packages that use bashisms unnecessarily, and so encourage some or all of those to be rendered in posix instead, then the world will have become a better place for embedded developers. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp7fCEgLI286.pgp Description: PGP signature
Re: Moving bash from essential/required to important?
Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. And third. The correct way to manage /bin/sh is as a configuration file. That means: * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. Policy 10.7.4 (Sharing configuration files) spells this out. It doesn't have much to do with whether dependencies on bash are made explicit. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405210530.GA13445@elie
Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. And third. The correct way to manage /bin/sh is as a configuration file. That means: * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. Policy 10.7.4 (Sharing configuration files) spells this out. It doesn't have much to do with whether dependencies on bash are made explicit. Well, that will only happen when it's cristal clear that it's guaranteed that /bin/sh exists and is functional at all times in such a scenario. You are welcome to implement such a solution, but if it does not meet the above criterion, it will very probably not be adopted. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9b8580.6010...@debian.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* Luk Claes [2011-04-05 23:11 +0200]: On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. The correct way to manage /bin/sh is as a configuration file. Of course it is. * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar How would debootstrap be able to run the preinst scripts without a working /bin/sh, unless it runs bash's binary one first? * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. update-alternatives is (among other things) because of the indirection it uses the wrong tool, but a part of it fits rather good. Such a tool would need to support priorities to select per default dash as /bin/sh, if dash is not installed it would select bash and if both are missing it would select an other shell. It would also need to assure that whilst it is running /bin/sh is always functional. Passing a shell to it that is not included in /etc/shells could lead to failing of this tool, unless --force is used. Well, that will only happen when it's cristal clear that it's guaranteed that /bin/sh exists and is functional at all times in such a scenario. 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. Running update-shells in postinst and prerm (and never in the other two) would additionally be required to ensure that /bin/sh is always functional. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405235520.ga5...@furrball.stateful.de
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On 04/06/2011 01:55 AM, Carsten Hey wrote: * Luk Claes [2011-04-05 23:11 +0200]: On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, 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. One of the problems being what to do when you remove one of the shells (for instance the one providing /bin/sh)... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9bf825.4090...@debian.org
Re: Moving bash from essential/required to important?
On 2011-04-04, Luk Claes l...@debian.org wrote: What do others think of moving bash to important (required and important are part of the base system)? Just to make sure, you are essentially (ha!) talking about dropping Essential:yes from bash? /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnipjre7.rvp.nos...@sshway.ssh.pusling.com
Re: Moving bash from essential/required to important?
On Apr 04, Luk Claes l...@debian.org wrote: The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. This looks like a good enough reason to me to not bother. -- ciao, Marco signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Mon, Apr 4, 2011 at 18:04:20 +0200, Luk Claes wrote: Hi bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I think it'd be mostly a waste of time. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404161942.gp3...@radis.liafa.jussieu.fr
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I think we should avoid doing this for quite a different reason from the other responders. Consider that 'base-passwd' and 'login' are also part of the essential set. Why? Because being able to log in as root is part of the minimal set of functionality that must be available and usable on the system at all times. So if we drop bash from essential, how do we guarantee that root can log in? Do we set root's default shell to /bin/sh instead? I don't think anyone would be happy with that except those people who already change it to zsh anyway. :-) If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404175951.ga31...@scru.org
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 05:59:51PM +, Clint Adams wrote: On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. Likewise. Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] +1 However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. The list is 128 kilobytes long, so I don't attach it. I've put it on the web at http://files.liw.fi/temp/bash.list for anyone who wants a look. I have attached the scripts to make it easier for others to re-run them if they wish. Changing 543 packages to add a bash dependency does sound like a lot, but it should be doable. * We can add a lintian warning, which helps catch such things in the future. * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. * Or we might do a more traditional transition, with an MBF now, and a targeted NMU campaign in six months, for any packages that still remain. I think this would be a nice thing to do, especially from the point of view of embedded systems, and other systems with no interactive use, but limited resources. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ unpack-debian-binaries Description: application/shellscript find-bash-scripts Description: application/shellscript isbash Description: application/shellscript
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On 04/04/2011 09:32 PM, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. Does this include the instances of maintainer scripts (postinst etc)? I guess it will be even more. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9a3024.9040...@debian.org
Re: Moving bash from essential/required to important?
On 04/04/2011 10:42 PM, Steve Langasek wrote: On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? What about Roger's suggestion to have the root account passwordless and locked with sudo access? Are there other drawbacks to that proposal (is booting in single user mode covered for instance?)? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). I guess this is not so much an issue anymore when the account is locked? And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. In single user mode this would still be the case I guess? Though that would not have a big impact anymore I guess? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9a3175.1030...@debian.org
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 11:00:37PM +0200, Luk Claes wrote: On 04/04/2011 10:42 PM, Steve Langasek wrote: On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? What about Roger's suggestion to have the root account passwordless and locked with sudo access? Are there other drawbacks to that proposal (is booting in single user mode covered for instance?)? How does that address the problem of getting a root shell to recover a system that's gone south in the middle of an upgrade? Do you intend to have a *user* account with sudo privileges that has /bin/sh as a default login shell? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). I guess this is not so much an issue anymore when the account is locked? And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. In single user mode this would still be the case I guess? Though that would not have a big impact anymore I guess? Essential is all about the corner cases. One of those corner cases is that you've lost power in the middle of an upgrade and everything above the Essential set has been left in an inconsistent and unusable state. This rarely happens, but the Policy definition of Essential is our guarantee that when Murphy *does* have his way with your system, you don't need to resort to rescue media to recover it provided you have access to the console. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
Package: login
Version: 1:4.1.4.2+svn3283-3
Severity: wishlist
Tags: patch
Hi!
On Mon, 2011-04-04 at 10:16:35 -0700, Steve Langasek wrote:
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote:
What do others think of moving bash to important (required and important
are part of the base system)?
I also think this would be great!
Consider that 'base-passwd' and 'login' are also part of the essential set.
Why? Because being able to log in as root is part of the minimal set of
functionality that must be available and usable on the system at all times.
So if we drop bash from essential, how do we guarantee that root can log in?
Do we set root's default shell to /bin/sh instead? I don't think anyone
would be happy with that except those people who already change it to zsh
anyway. :-)
Well, we can always fix login to behave more robustly, no? :)
If login worked consistently in the face of the configured shell going
missing (automatically falling back to /bin/sh for root), then I think it
would be worthwhile to do the work necessary to remove bash from the
essential set. But until then, the primary purpose of Essential, to me, is
the minimal set guaranteed to be usable aspect, not the you don't have to
depend on it aspect.
That's more or less what the attached patch does. It could certainly be
improved, as the knowledge of when to fallback is spread all over the
place, but that's an existing problem in the code anyway.
The SHELL variable in configure.in is changed to an explicit /bin/sh
because relying on $SHELL might change depending on the shell used for
configure, and the existing code expects /bin/sh for fallback and script
invokation cases, this could be considered a bug on its own though. The
only fishy point is when calling shell() with a second argument, which
will get preserved, and might not quite match what was invoked
afterwards, but probably not worth worrying.
The code could also warn that it needed to fallback to a POSIX shell,
but I'm not sure what's the policy from the shadow code PoV here.
Tested with:
# chsh root -s /bin/csh
chsh: Warning: /bin/csh does not exist
# su
# echo $SHELL
/bin/sh
# exit
# su -
# echo $SHELL
/bin/sh
# exit
# login -f root
Last login: Tue Apr 5 01:36:13 CEST 2011 on pts/10
# echo $SHELL
/bin/sh
And on a virtual console.
regards,
guillem
diff --git a/configure.in b/configure.in
index 4021479..585bdb1 100644
--- a/configure.in
+++ b/configure.in
@@ -574,7 +574,7 @@ if test $enable_utmpx = yes; then
[Define if utmpx should be used])
fi
-AC_DEFINE_UNQUOTED(SHELL, [$SHELL], [The default shell.])
+AC_DEFINE_UNQUOTED(SHELL, [/bin/sh], [The default shell.])
AM_GNU_GETTEXT_VERSION(0.16)
AM_GNU_GETTEXT([external], [need-ngettext])
diff --git a/libmisc/setupenv.c b/libmisc/setupenv.c
index 666b1c7..601430f 100644
--- a/libmisc/setupenv.c
+++ b/libmisc/setupenv.c
@@ -241,7 +241,8 @@ void setup_env (struct passwd *info)
* Create the SHELL environmental variable and export it.
*/
- if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell)) {
+ if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell) ||
+ access (info-pw_shell, R_OK|X_OK) != 0) {
static char temp_pw_shell[] = SHELL;
info-pw_shell = temp_pw_shell;
diff --git a/libmisc/shell.c b/libmisc/shell.c
index d815f2d..5634580 100644
--- a/libmisc/shell.c
+++ b/libmisc/shell.c
@@ -53,6 +53,7 @@ extern size_t newenvc;
int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
{
+ const char *fallback_arg;
char arg0[1024];
int err;
@@ -71,6 +72,10 @@ int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
(void) snprintf (arg0, sizeof arg0, -%s, Basename ((char *) file));
arg0[sizeof arg0 - 1] = '\0';
arg = arg0;
+
+ fallback_arg = -sh;
+ } else {
+ fallback_arg = arg;
}
/*
@@ -81,7 +86,14 @@ int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
(void) execle (file, arg, (char *) 0, envp);
err = errno;
- if (access (file, R_OK|X_OK) == 0) {
+ if (err == ENOENT) {
+ /*
+ * The requested shell does not seem to be present,
+ * fallback to a POSIX shell.
+ */
+ (void) execle (SHELL, fallback_arg, (char *)0, envp);
+ err = errno;
+ } else if (access (file, R_OK|X_OK) == 0) {
/*
* Assume this is a shell script (with no shebang).
* Interpret it with /bin/sh
diff --git a/src/su.c b/src/su.c
index f3ff666..12bd03b 100644
--- a/src/su.c
+++ b/src/su.c
@@ -759,7 +759,8 @@ int main (int argc, char **argv)
/*
* Set the default shell.
*/
- if ((NULL == shellstr) || ('\0' == shellstr[0])) {
+ if ((NULL == shellstr) || ('\0' == shellstr[0]) ||
+ access (pwent.pw_shell, R_OK|X_OK) != 0) {
shellstr = SHELL;
}
Re: Moving bash from essential/required to important?
Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Fix #428189, either by adapting the policy to reality or vice versa (depending on the maintainers decision) as prerequisite to fix the next point without breaking things afterwards. * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. * Lars Wirzenius [2011-04-04 20:32 +0100]: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. The login approach mentioned in this thread is in my opinion way more clean than fiddling with /etc/passwd. However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. gzip_1.3.12-9_amd64.deb contains files in /bin/ starting with #!/bin/bash, maybe your script skips /bin/? The post installation script of libssl1.0.0.0 also contains a bash shebang line missed by your script. Changing 543 packages to add a bash dependency does sound like a lot, but it should be doable. * We can add a lintian warning, which helps catch such things in the future. This would also require an exception to the don't depend on essential warning. * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. Ack. * Or we might do a more traditional transition, with an MBF now, and a targeted NMU campaign in six months, for any packages that still remain. This sounds more like a possible release goal to me and not like something that needs to be fixed using NMUs in a few months. I think this would be a nice thing to do, especially from the point of view of embedded systems, and other systems with no interactive use, but limited resources. I agree about the usefulness for embedded systems and think that (if there is some work done in this direction) the efforts should be done with them in mind. After all, deciding things that can't be done because of others blocking it is not the best idea. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011040536.ga10...@furrball.stateful.de
Re: Moving bash from essential/required to important?
On Tue, 2011-04-05 at 01:49 +0200, Guillem Jover wrote: [...] Well, we can always fix login to behave more robustly, no? :) If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. That's more or less what the attached patch does. It could certainly be improved, as the knowledge of when to fallback is spread all over the place, but that's an existing problem in the code anyway. [...] This appears to open up any accounts that have been deliberately disabled by setting their shell to a nonexistent path. I know that's a dumb way to disable an account, but that doesn't make this any less of a security hole. How about checking for the configured shell in /etc/shells before enabling the fallback? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. A kludge that might work: let's have root's shell set to /bin/bash by default regardless if bash is installed, and silently fall back if it's not. The fallback is good thing in any case -- if someone changes root's shell to zsh or sash then accidentally removes it, getting /bin/sh instead is nice. However, there have got to be hundreds of packages using bash without a dependency. [...] * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. Removal of the essential flag won't happen sooner than after a full release cycle anyway, so this suggestion sounds like a good idea. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405004354.ga25...@angband.pl
Re: Moving bash from essential/required to important?
Thanks for looking at this! I'd definitely be happy to see a solution that lets us shrink our Essential set without making the system less robust. On Tue, Apr 05, 2011 at 01:49:17AM +0200, Guillem Jover wrote: If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. That's more or less what the attached patch does. Yes, it seems to handle the missing-shell case. What about the case of execle() failing? It's at least as likely for a shell to be broken because its dependencies are not yet unpacked as it is that it's broken because the shell itself is not unpacked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Fix #428189, either by adapting the policy to reality or vice versa (depending on the maintainers decision) as prerequisite to fix the next point without breaking things afterwards. This doesn't appear to be relevant to moving bash out of Essential. dash, which would still be Essential (no one is proposing removing /bin/sh from Essential!), also has printf as a shell builtin. It would be good to resolve this bug in its own right, but it appears to be orthogonal to whether bash is Essential. * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. Also seems to be orthogonal. * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. Do you know what exactly it is about dash that autoconf believes is not POSIX-compliant? My understanding was that dash *is* POSIX-compliant, but that this is not enough to satisfy autoconf's specific requirements. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
Steve Langasek vor...@debian.org writes: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. Do you know what exactly it is about dash that autoconf believes is not POSIX-compliant? My understanding was that dash *is* POSIX-compliant, but that this is not enough to satisfy autoconf's specific requirements. dash doesn't support $LINENO, which is why it's not detected by Autoconf. The reason why it doesn't support $LINENO (it's intentional; we had a patch to add it that was then removed) is that the configure.ac files of many, many packages contain bashisms that dash doesn't support. If $LINENO support is present in dash, Autoconf considers dash sufficiently POSIX to use as the configure shell, and then all those packages FTBFS. This is, without question, a bug in every package that has a configure.ac script that assumes bash. The problem is that there are apparently a whole ton of them, and convincing upstream to care is in some cases going to be hard. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952 for the gory details. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei5h76kj@windlord.stanford.edu
Re: Moving bash from essential/required to important?
[Roger Leigh] Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. That brings up something I think all interactive shells should do: in 'prerm remove', check to see if you are root's login shell, and if so, give the admin an opportunity to abort the removal. (Or even offer to run chsh, though that's pretty out of scope for a maintainer script.) bash should do this, but so should the other shells. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405030854.gb3...@p12n.org
Re: Moving bash from essential/required to important?
On Tue, 2011-04-05 at 01:08:19 +0100, Ben Hutchings wrote:
This appears to open up any accounts that have been deliberately
disabled by setting their shell to a nonexistent path. I know that's a
dumb way to disable an account, but that doesn't make this any less of a
security hole.
How about checking for the configured shell in /etc/shells before
enabling the fallback?
Ah good catch! Done with the attached patch.
On Mon, 2011-04-04 at 18:10:48 -0700, Steve Langasek wrote:
Yes, it seems to handle the missing-shell case. What about the case of
execle() failing? It's at least as likely for a shell to be broken because
its dependencies are not yet unpacked as it is that it's broken because the
shell itself is not unpacked.
Well, ENOENT should handle not only missing executable, also missing
dynamic linker, etc. Maybe missing shared libraries depending on the
implementation, but on glibc systems, because those are handled by
the dynamic linker it's too late as the kernel has already handed over
control to it, which will fail hard. Equivalent to the case of the
shell binary segfaulting. Those cases would need to be handled
by forking and watching the childs (ugh :). In any case I've now
relaxed the ENOENT case to just execute the fallback when
apropriate on any execle() error, in case there's other error
instances which might make sense to fallback on.
But then bash only depends on libc and libncurses, which are
pseudo-essential, so if those and the dynamic linker are
non-functional then the system has bigger problems than root not
being able to login. For the unpack case you mention I guess it would
just be a matter of keeping those libraries in the Pre-Depends when
removing it from Essential.
Something else to do would be to add a versioned dependency to bash
on the fixed login package.
Would all this address your concerns?
regards,
guillem
diff --git a/configure.in b/configure.in
index 4021479..585bdb1 100644
--- a/configure.in
+++ b/configure.in
@@ -574,7 +574,7 @@ if test $enable_utmpx = yes; then
[Define if utmpx should be used])
fi
-AC_DEFINE_UNQUOTED(SHELL, [$SHELL], [The default shell.])
+AC_DEFINE_UNQUOTED(SHELL, [/bin/sh], [The default shell.])
AM_GNU_GETTEXT_VERSION(0.16)
AM_GNU_GETTEXT([external], [need-ngettext])
diff --git a/lib/prototypes.h b/lib/prototypes.h
index 1f6e5b3..76c84b3 100644
--- a/lib/prototypes.h
+++ b/lib/prototypes.h
@@ -337,6 +337,8 @@ extern void spw_free (/*@out@*/ /*@only@*/struct spwd *spent);
/* shell.c */
extern int shell (const char *file, /*@null@*/const char *arg, char *const envp[]);
+extern bool shell_is_listed (const char *sh);
+extern bool shell_must_fallback (const char *sh);
/* system.c */
extern int safe_system (const char *command,
diff --git a/libmisc/setupenv.c b/libmisc/setupenv.c
index 666b1c7..7e8ab41 100644
--- a/libmisc/setupenv.c
+++ b/libmisc/setupenv.c
@@ -241,7 +241,8 @@ void setup_env (struct passwd *info)
* Create the SHELL environmental variable and export it.
*/
- if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell)) {
+ if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell) ||
+ shell_must_fallback (info-pw_shell)) {
static char temp_pw_shell[] = SHELL;
info-pw_shell = temp_pw_shell;
diff --git a/libmisc/shell.c b/libmisc/shell.c
index d815f2d..6bc5b1d 100644
--- a/libmisc/shell.c
+++ b/libmisc/shell.c
@@ -42,6 +42,84 @@ extern char **newenvp;
extern size_t newenvc;
/*
+ * shell_is_listed - see if the user's login shell is listed in /etc/shells
+ *
+ * The /etc/shells file is read for valid names of login shells. If the
+ * /etc/shells file does not exist the user cannot set any shell unless
+ * they are root.
+ *
+ * If getusershell() is available (Linux, *BSD, possibly others), use it
+ * instead of re-implementing it.
+ */
+bool shell_is_listed (const char *sh)
+{
+ char *cp;
+ bool found = false;
+
+#ifndef HAVE_GETUSERSHELL
+ char buf[BUFSIZ];
+ FILE *fp;
+#endif
+
+#ifdef HAVE_GETUSERSHELL
+ setusershell ();
+ while ((cp = getusershell ())) {
+ if (*cp == '#') {
+ continue;
+ }
+
+ if (strcmp (cp, sh) == 0) {
+ found = true;
+ break;
+ }
+ }
+ endusershell ();
+#else
+ fp = fopen (SHELLS_FILE, r);
+ if (NULL == fp) {
+ return false;
+ }
+
+ while (fgets (buf, sizeof (buf), fp) == buf) {
+ cp = strrchr (buf, '\n');
+ if (NULL != cp) {
+ *cp = '\0';
+ }
+
+ if (buf[0] == '#') {
+ continue;
+ }
+
+ if (strcmp (buf, sh) == 0) {
+ found = true;
+ break;
+ }
+ }
+ fclose (fp);
+#endif
+ return found;
+}
+
+/*
+ * shell_must_fallback - see if must fallback to the default POSIX shell
+ *
+ * Check if the shell specified does not exist, but is known in /etc/shells,
+ * and thus it's safe to fallback to the default POSIX shell. Otherwise
+ * user accounts disabled by setting the login shell to a non-existent path
+ * would be allowed which is not what we want.
+ */
+bool shell_must_fallback (const char *sh)
+{
+ if (access (sh, R_OK|X_OK) == 0)
+
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 06:19:38AM +0200, Guillem Jover wrote: But then bash only depends on libc and libncurses, which are pseudo-essential, so if those and the dynamic linker are non-functional then the system has bigger problems than root not being able to login. For the unpack case you mention I guess it would just be a matter of keeping those libraries in the Pre-Depends when removing it from Essential. That's true for bash, but might not be true for other shells... as long as we're proposing to change this in login, I'd like it to be as robust as we can make it. Also: libncurses is pseudo-essential, but the soname could of course change in the future... unpack new bash without first unpacking libncurses6 (if we suppose we're *not* requiring bash to obey the usable-while-unpacked rule which causes bash to currently pre-depend on its shlib deps), or unpack new essential packages which force *removal* of libncurses5 in favor of libncurses6, thus leaving bash unpacked yet broken, and a trap that catches a failure to load shared libs becomes useful even for bash. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
