On Tue, 27 Mar 2012 21:14:57 +0200 Gian Piero Carrubba wrote: > * [Sun, Mar 25, 2012 at 11:48:57PM +0200] Francesco Poli: > >For the time being, the only way to dodge this problem is maybe to > >avoid invoking "su -c", even when in an sudo environment. > >This means that the browser will run as root, even when apt-listbugs is > >invoked through sudo. > [...] > >What do you think about this proposal? > >Would you consider it as an acceptable interim fix, while waiting for > >the radical solution? > > Hi Francesco, > > considering it as a temporary work around, I suppose it is acceptable, > even though I for myself am not excited launching a browser as root.
I can understand. And indeed, I usually upgrade my boxes by issuing the following commands: $ su - Password: # aptitude update ; aptitude --purge-unused safe-upgrade Hence, using the "w" command within apt-listbugs prompt would lead me to launch a browser as root, since I don't use sudo. Guess what? I almost never use the "w" command... > Another possibility could be using sudo instead of su. As $SUDO_USER is > set, it should be safe to think sudo is installed, unless the same > variable is also used from some sudo-like alternatives (super or so). I > didn't verify it. Mmmh, I don't think we can assume that sudo is installed, just because we are within an sudo environment (with $SUDO_USER set). Maybe we are inside a chroot environment and we entered by using sudo from the outside. Package sudo is *not* necessarily installed *inside* the chroot environment... > Anyway, having set apart for the moment a general solution, could you > please give another try to the patch I've previously sent? I'm using it > on some of my PCs and it seems to work correctly. > Since from the report of the bad behaviour you've experienced, I had > tried to reproduce it without success. I think the key of the failure > could be the chroot environment, but until now I've failed to reproduce > it both with schroot and a "plain" chroot. I've just re-tested your proposed modification. I still experience the impossibility to interact with w3m... :-( > In the next day or two I plan > to try again, but I'm a bit in shortage of ideas about the cause and I'm > beginning to believe that either your environment is more esoteric than > what I could think of or I'm really missing some trivial point. My "esoteric" environment is just a pbuilder-managed sid chroot. Its setup is described here: http://www.inventati.org/frx/doc/nanodocs/testing_workstation_programming.html#setting-up-chroots-for-building-debian-packages After rebuilding apt-listbugs with your proposed modification, I enter the chroot environment (B50shell_pdeb hook script), I install apt-listbugs, sudo, w3m, and adduser from sid (with aptitude), then I install the rebuilt apt-listbugs (with dpkg), and I add the pbuser user to the sudo group. At that point I "su - pbuser" and feed some apt hook version 2 protocol data to apt-listbugs (your script is perfectly fine for this job). If I do that with sudo (to gain root privileges for the pbuser user), and I try to display bugs with w3m, I am unable to interact with the browser, as previously explained... > As for > reference, I'm attaching the simple test I'm using when not testing the > whole aptitude/apt-listbugs pair. The test.sh script should be run via > sudo in order to emulate (at least I think so) aptitude. Could you > please state if there's something clearly wrong with it? I fail to see anything wrong with it (even though I don't understand the use of the $n variable in "read p v n"...) > > Thanks, Thanks to you, for the time you are spending trying to help me with this bug! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpUbXZdI6az7.pgp
Description: PGP signature
