Bug#317264: login: Current su breaks pbuilder
Package: login Version: 1:4.0.3-36 Severity: important Whenever I try to use pbuilder to build a package after upgrading the chroot today, I get: ... Copying source file -> copying [gphoto2_2.1.6-1.dsc] -> copying [./gphoto2_2.1.6.orig.tar.gz] -> copying [./gphoto2_2.1.6-1.diff.gz] Extracting source /usr/bin/dpkg-source: line 3: my: command not found /usr/bin/dpkg-source: line 4: my: command not found /usr/bin/dpkg-source: line 6: my: command not found /usr/bin/dpkg-source: line 7: my: command not found /usr/bin/dpkg-source: line 8: my: command not found /usr/bin/dpkg-source: line 9: my: command not found /usr/bin/dpkg-source: line 11: =: command not found /usr/bin/dpkg-source: line 13: =: command not found /usr/bin/dpkg-source: line 14: =: command not found /usr/bin/dpkg-source: line 15: =: command not found /usr/bin/dpkg-source: line 16: =: command not found /usr/bin/dpkg-source: line 18: use: command not found /usr/bin/dpkg-source: line 19: syntax error near unexpected token `(' /usr/bin/dpkg-source: line 19: `use POSIX qw (:errno_h :signal_h);' Running the pbuilder-buildpackage backend using sh -x, the command which is failing is: + chroot /var/cache/pbuilder/build//7737 /bin/bash -c '( cd tmp/buildd; chown pbuilder:pbuilder ../buildd *; su -p pbuilder -- /usr/bin/dpkg-source -x gphoto2_2.1.6-1.dsc )' And in fact, setting up a directory with proper permissions and a test source package, I can also reproduce this outside pbuilder: frobnitz:/tmp/kdenetwork# su -p daniel -- dpkg-source -x kdenetwork_3.3.2-6.dsc /usr/bin/dpkg-source: line 3: my: command not found /usr/bin/dpkg-source: line 4: my: command not found ... -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages login depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l login recommends no packages. -- no debconf information -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
On Thu, Jul 07, 2005 at 12:37:17PM +0200, Nicolas François wrote: > Hello Daniel, > > This was introduced by the patch for #276419, which I still approve. > Here is a fix for pbuilder. It doesn't work. > (I'm CCing the pbuilder maintainer to have his opinion, before reassigning > this bug to pbuilder) > > Note: This may require a versioned dependancy. > > ("su -- arg1 arg2" used to run " -c arg1 arg2" and it now > launch " arg1 arg2", so a pbuilder with this patch and an old su > will run " -c -c arg1 arg2", which is not an issue for bash, but > may be annoying for another shell) Actually 'su -- arg1 arg2' used to run ' -c "arg1 arg2"' (ie arg1 and arg2 are grouped as one argument) and now it runs ' arg1 arg2' and ' -c arg1 arg2' with your patch. That's why your patch doesn't work as arg2 is ignored. Please find attached a new patch that works with both the old and new version of su (it is not possible to have a versioned dependency as it is the su from inside the chroot which is called). Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net --- pbuilder-buildpackage.orig 2005-07-02 08:33:47.0 +0200 +++ pbuilder-buildpackage 2005-07-07 17:11:10.190515660 +0200 @@ -32,7 +32,7 @@ fi; if [ -n "$BUILDUSERNAME" -a -n "$BUILDUSERID" ]; then -SUTOUSER="su -p $BUILDUSERNAME -- " +SUTOUSER="su -p $BUILDUSERNAME -c " DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot" EXTRAPACKAGES="${EXTRAPACKAGES} fakeroot" echo "I: using fakeroot in build." @@ -81,7 +81,7 @@ copydsc "$PACKAGENAME" "$BUILDPLACE/tmp/buildd" echo "Extracting source" -if ! $CHROOTEXEC /bin/bash -c "( cd tmp/buildd; chown $BUILDUSERNAME:$BUILDUSERNAME ../buildd *; $SUTOUSER /usr/bin/dpkg-source -x $(basename $PACKAGENAME) )"; then +if ! $CHROOTEXEC /bin/bash -c "( cd tmp/buildd; chown $BUILDUSERNAME:$BUILDUSERNAME ../buildd *; $SUTOUSER \"/usr/bin/dpkg-source -x $(basename $PACKAGENAME) \")"; then echo "pbuilder: Failed extracting the source" >&2 exit 1; fi
Bug#317264: login: Current su breaks pbuilder
Hi, > Actually 'su -- arg1 arg2' used to run ' -c "arg1 arg2"' > (ie arg1 and arg2 are grouped as one argument) and now it runs ' > arg1 arg2' and ' -c arg1 arg2' with your patch. > > That's why your patch doesn't work as arg2 is ignored. > > Please find attached a new patch that works with both the old and new > version of su (it is not possible to have a versioned dependency as it > is the su from inside the chroot which is called). Why is su changing behavior? I have concerns wrt shell quoting, and I'd rather not require this patch. regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
Junichi Uekawa <[EMAIL PROTECTED]> writes: >Why is su changing behavior? Old su doesn't meet its specifications (i.e. manual page). Please see Bug#276419 for a detailed discussion. For example, according to the su manual page, $ su - userid -xs 'startup parameter' should start an interactive login shell with debug mode switched on and supply the additional positional argument "startup parameter" to it rather than starting an noninteractive login shell with the positional arguments "-c" "-xs startup parameter", i.e. a commandline "-xs startup parameter" and no additional positional arguments. With (old) su, you cannot pass additional positional arguments and options (other than "-c") to the shell. >I have concerns wrt shell quoting, Could you please explain more detailed? Best regards, Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann <[EMAIL PROTECTED]>, (Helmut Waitzmann) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
Hi, Apart from being unhappy about a core component of Debian dramatically changing at all; to answer your question: > >I have concerns wrt shell quoting, > > Could you please explain more detailed? The implications of needing quoting means that previous quoting conventions will need to change. Applications which used to pass quoted text to su, and needs to quote differently now need to change dramatically. su username command A $B "C $D" used to work, but it will now need to be su username -c "command A \"$B\" \"C $D\"" and specific semantics of how the contents of $B and $D is expanded is going to change. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
Junichi Uekawa <[EMAIL PROTECTED]> writes: >Apart from being unhappy about a core component of >Debian dramatically changing at all; to answer your >question: > >> >I have concerns wrt shell quoting, >> >> Could you please explain more detailed? > >The implications of needing quoting means that previous >quoting conventions will need to change. > >Applications which used to pass quoted text to su, and >needs to quote differently now need to change dramatically. That would be intolerable, indeed. But see below. > su username command A $B "C $D" >used to work, but it will now need to be > su username -c "command A \"$B\" \"C $D\"" No. With Debian's new su one would have to do (suppose one is using a bourne shell or compatible) to achieve the same result: $ (set x command A $B "C $D" && shift && exec su username -c "$*") >and specific semantics of how the contents of $B and $D is expanded is >going to change. No. $B and $D are expanded by the shell invoking su, not by the shell invoked by su. So there will be no change w.r.t. to $B and $D. There will be a change in concatenating: Debian's new su will not concatenate the parameters to make up a command string. So you have to do it yourself. That's what the 'set' command in conjunction with the special parameter "$*" does. But this feature of Debian's old su (i.e. concatenating the command arguments), is an undocumented feature: It is not documented in Debian's old su's manual page. So every invocation of su that adheres to the specification of Debian's old su won't use it anyway but concatenate all command string components by itself. The feature of Debian's old su to implicit pass a "-c" parameter to the shell if there are any arguments following the username, is undocumented, too. So every conforming invocation of su would supply "-c" by itself and not relay on su doing it implicitly. And what about quoting? No. There will be no change in quoting, because old su (like every su) does no quoting by itself, it simply concatenates the arguments. You may call this a bug of su, but it is not: Su does not know anything about quoting for username's shell it is going to start. As there are different shells (sh, bash, csh, tcsh, ksh, ash, some people use even emacs, ...) with different ways to quote, su cannot know how to quote the parameters before constructing a command to be executed by username's shell. So what does Debian's old su do, when it constructs the command to be executed by the username's shell? It does'nt do any quoting. It simply concatenates all the arguments into one string with spaces in between and supplies that string as the command string to the shell to be called. An example may illustrate this. In the following, I assume, that the shell to enter this commands into is a bash and that the username's shell (that will be invoked by su) is a bash, too: Don't do this at home! $ su -- username 'ls' '--' 'white space' 'a fancy name; rm -rf ~' Here, su is called with 6 parameters: '--', 'username', 'ls', '--', 'white space' and 'a fancy name; rm -rf ~'. Note, that the single quotes are not part of the parameters, as seen by su. I write them in this text to indicate the start and the end of each of the parameters (which may contain white space). Su will get the 6 parameters without the quotes as positional parameters. The single quotes in the command line are necessary, to indicate to the bash invoking su what the parameters to pass to su are to be. Debian's old su will notice, that the first parameter after the username (i.e. 'ls') is not a su option (see manual page su), so it assumes, that it is one of the words to be concatenated to make up the command string to pass to username's shell to be invoked. Therfore, Debian's old su will invoke the username's bash as follows (note, that the parameters to su are simply concatenated with spaces in between, no additional level of quoting is done by su): $ bash -c 'ls -- white space a fancy name; rm -rf ~' What will that bash, that is invoked by su, do? To understand, what will happen, take a look at the manual page bash(1): BASH(1) NAME bash - GNU Bourne-Again SHell SYNOPSIS bash [options] [file] [...] OPTIONS In addition to the single-character shell options documented in the description of the set builtin command, bash interprets the following options when it is invoked: -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. So, username's bash will execute the following two commands (note the semicolon!): $ ls -- white space a fancy name; rm -rf ~ Do I have to comment, what will happen? To achieve the same (bad) result using Debian's both old or new su, Linux Standard Base's
Bug#317264: [Pkg-shadow-devel] Bug#317264: login: Current su breaks pbuilder
Quoting Daniel Schepler ([EMAIL PROTECTED]): > Package: login > Version: 1:4.0.3-36 > Severity: important > > Whenever I try to use pbuilder to build a package after upgrading the > chroot today, I get: > frobnitz:/tmp/kdenetwork# su -p daniel -- dpkg-source -x > kdenetwork_3.3.2-6.dsc > /usr/bin/dpkg-source: line 3: my: command not found > /usr/bin/dpkg-source: line 4: my: command not found This is very likely to be the "fix" for #276419 which is culprit here. Other team members, who looks more closely at this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: [Pkg-shadow-devel] Bug#317264: login: Current su breaks pbuilder
> > Whenever I try to use pbuilder to build a package after upgrading the > > chroot today, I get: > > > frobnitz:/tmp/kdenetwork# su -p daniel -- dpkg-source -x > > kdenetwork_3.3.2-6.dsc > > /usr/bin/dpkg-source: line 3: my: command not found > > /usr/bin/dpkg-source: line 4: my: command not found > > > This is very likely to be the "fix" for #276419 which is culprit here. > > Other team members, who looks more closely at this? For the record: >From the #shadow IRC channel, here is Nicolas François (nekral) analysis: 01:06 < nekral> hi 01:09 < nekral> I'm looking at the log and here are clarifications of my thought 01:12 < nekral> in #276419, we were asked not to concatenate all arguments before passing them to the shell (or command if -c) 01:15 < nekral> Another point was asked by 276419-submitter: not to add a -c argument to the executed shell when no command was provided to su (with -c) 01:16 < nekral> regarding the first point: 01:16 < nekral> * the old behavior was not documented ("Any arguments supplied after the username will be passed to the invoked shell") 01:18 < nekral> * the old behavior differ from current upstream (and probably from other distribution, upstream using a patch from redhat) 01:19 < nekral> * applications requiring that the arguments are concatenated should concatenate themself 01:19 < nekral> Then regarding the second point: 01:21 < nekral> * the man page does not indicate that -c is inserted in the list of arguments provided to the shell 01:24 < nekral>(thus "su - $USERNAME -- -x" should work and should execute a shell in debug mode (the arguments should be [, "-x"] and not [, "-c", ""-x"]) 01:31 < nekral> Then, if too many packages relied on the previous behavior, and if only 276419-submitter push for the applied patch, then a pragmatical approch could be to revert 01:31 < nekral> (We can also only revert one of the above points) 01:33 < nekral> Zugschlus, I don't understand the point about your "clamav-data testing script on debian-volatile" 01:34 < nekral> did it occured with login 4.0.3-36? 01:34 < nekral> "su - $ACCOUNT -c bash" works nicely with login 4.0.3-36 01:37 < nekral> (also, I can't find any reference to su in "clamav-data) 07:42 < Zugschlus> fsck, nekral isn't there 07:43 < Zugschlus> the testing script is not part of the package
Bug#317264: [Pkg-shadow-devel] Bug#317264: login: Current su breaks pbuilder
Quoting Junichi Uekawa ([EMAIL PROTECTED]): > > Hi, > > Apart from being unhappy about a core component of I would actually appreciate that the "I am unhappy" comments about this issue are taken away now. We have put a lot of efforts in solving the thing as quickly as possible, you know..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317264: [Pkg-shadow-devel] Bug#317264: login: Current su breaks pbuilder
> > Apart from being unhappy about a core component of > > > I would actually appreciate that the "I am unhappy" comments about > this issue are taken away now. We have put a lot of efforts in solving > the thing as quickly as possible, you know..:) Okay; I'll just express that I forsee a bit more trouble while this transition takes place in sid. regards, junichi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]