Bug 4723

Summary:	2_b1: $PATH contains path=/bin:/usr/bin:.....
Product:	Mageia	Reporter:	Bit Twister <bittwister2>
Component:	RPM Packages	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	Normal	CC:	joequant, mageia
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	util-linux-2.21-2.mga2.src.rpm	CVE:
Status comment:

Description Bit Twister 2012-02-27 16:28:50 CET

Description of problem:

$PATH contains path=/bin:/usr/bin:....
instead of     /bin:/usr/bin:....

Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. clean install of beta1
2. Pick Custom, in Workstation select all but Documentation, Games and LSB
   select everything in Server, 
   in Graphical Environment select KDE
   select Individual packages selection. Add xterm, emacs and emacs-nox
   uncheck GUI startup in Graphical interface to set system 
   to boot runlevel 3
3. login and note no errors
4. startx
5. click up a terminal
6. su - root
7. urpme mgaonline
8. urpme --auto-orphans
9. mcc->Software Management->Configure media sources for install and update
   uncheck cdrom selection
   load Full Source medias and click OK
   back in the terminal do a

10. urpmi.remove -y Test test port ebug

11. mcc->Software Management->Configure media sources for install and update
   and enable all selections except cdrom and click OK and exit mcc
12. script -c "urpmi --downloader wget --auto --auto-update" /tmp/urpmi_test.log
13. reboot
14. login

You should see a bunch of errors caused by corrupted PATH.

15. echo $PATH

Comment 1 Remco Rijnders 2012-02-27 18:19:47 CET

Hi Bit Twister,

Thanks for the report. Is there any chance of illustrating the problem with a shorter set of instructions? For example, would it be possible for you to see which step changes the PATH? Perhaps by checking the modification time of .bashrc or what have you?

Comment 2 Bit Twister 2012-02-27 19:26:22 CET

(In reply to comment #1)
> Hi Bit Twister,
> 
> Thanks for the report. Is there any chance of illustrating the problem with a
> shorter set of instructions? 

Feel free to create a new guest in VirtualBox, set runlevel 3, apply updates and login to see if problem exists. I think it will recreate the problem.

I knocked my "Production" box into the ditch trying to figure out that problem.
I worked since 2am to 7am to get you that test procedure. 

> For example, would it be possible for you to see which step changes the PATH?

After clean install + update, system was hosed.  :(

> Perhaps by checking the modification time of .bashrc or what have you?

Yeah, right, problem is up line from /etc/profile. As I misunderstand it, you login, linux gets field 7 from /etc/passwd (/bin/bash) and turn control over to it.

/bin/bash runs /etc/profile which then runs "or what have you"  :)

I just now finished testing my workaround procedure in Mandriva and patched /cauldron/etc/profile.

Workaround is add the following kludge to /etc/profile after line 3.

PATH=${PATH#*path=}
export PATH

and I will be booting cauldron after I save this reply.

I hope whoever fixes the bug, tells us where the problem was found.

Comment 3 Bit Twister 2012-02-27 19:46:41 CET

Frap, this is one neat bug. Workaround is

PATH=/usr/local/bin:/usr/bin:/bin
export PATH


No idea why my substring code did not work. I'll play with that later.

Comment 4 Colin Guthrie 2012-02-28 00:10:32 CET

I'm seeing this too.

Doesn't seem to affect my X, just my getty....

CC: (none) => mageia

Comment 5 Colin Guthrie 2012-02-28 00:52:53 CET

Seems to be a bug in the latest util-linux...

Source RPM: (none) => util-linux-2.21-2.mga2.src.rpm

Comment 6 Bit Twister 2012-02-28 00:54:38 CET

(In reply to comment #4)
> I'm seeing this too.
> 
> Doesn't seem to affect my X, just my getty....

It is fatal for runlevel 3 users. None of the /bin apps used in /etc/profile
work.  :(

Comment 7 Colin Guthrie 2012-02-28 00:56:47 CET

Just for clarity, the problem is in the file /etc/login.defs which is actually from shadow-utils...

It seems both util-linux and shadow-utils provide a "login" binary.. (one on /bin/login and one in /usr/bin/login). We really need to provide only one of those.

Either way, I'll look into it.

Comment 8 Colin Guthrie 2012-02-28 01:31:15 CET

OK, fixed in latest util-linux.

FWIW, there are nasty overlaps between util-linux and shadow-utils... we really need to tidy them up (i.e. lots of rm'ing during install part of shadow-utils to remove all the things we don't want...

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Colin Guthrie 2012-02-28 01:31:38 CET

Assignee: bugsquad => mageia

Comment 9 Manuel Hiebel 2012-02-28 15:35:04 CET

*** Bug 4733 has been marked as a duplicate of this bug. ***

CC: (none) => joequant

Comment 10 Colin Guthrie 2012-02-28 15:37:39 CET

Just for reference, I spoke to upstream guy about this and there is now a better fix:
https://github.com/karelzak/util-linux/commit/607e6b7ce8658e552fdffbb99c51cdb01828e27b

(my patch is relatively hacky by comparison).

I'll update to this better patch when I get a chance (but it's not super urgent).