Bug 28550 - If UID is 500, the $PATH variable doesn't contains /usr/games, thus games can't be launched
Summary: If UID is 500, the $PATH variable doesn't contains /usr/games, thus games can...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords: IN_ERRATA8
Depends on:
Blocks:
 
Reported: 2021-03-08 08:23 CET by papoteur
Modified: 2021-04-04 15:02 CEST (History)
5 users (show)

See Also:
Source RPM: setup-2.7.25-1.mga8.src.rpm
CVE:
Status comment:


Attachments

Description papoteur 2021-03-08 08:23:39 CET
Description of problem:
For installation from successive migration, UID can be less than 1000. In this case, the PATH variable does include /usr/games nor /usr/local/games.

The cause is that /etc/profile contains:
# Path manipulation
if [ "$UID" -ge 1000 ] ; then
    pathmunge /usr/local/games after
    pathmunge /usr/games after
fi

This wasn't the case in Mageia 7 where the condition was -ge 500 instead of 1000.

As a consequence, some launchers of games aren't operational, like puzzle-dominosa
Comment 1 Aurelien Oudelet 2021-03-08 11:04:46 CET
It is recommended to have an USERID starting at 1000.

This can be done as root, by modifying /etc/passwd and later doing a
# chown -R 1000:1000 /home/papoteur ;)

I know this is annoying.


Assigning meanwhile to all packagers as no registered one.
Adding Olav who did the commit on this.

Keywords: (none) => FOR_ERRATA8
Source RPM: setup => setup-2.7.25-1.mga8.src.rpm
Assignee: bugsquad => pkg-bugs
CC: (none) => olav, ouaurelien

Aurelien Oudelet 2021-03-08 11:05:12 CET

CC: (none) => fri

Comment 2 Nicolas Lécureuil 2021-03-08 12:28:14 CET
this is a not a papoteur bug but one found in MLO.

The main issue is that it affects all users installed with mageia <= 6

CC: (none) => mageia

Comment 3 Morgan Leijström 2021-03-08 13:48:19 CET
Now in https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues, with usual link to bug.


Wouldnt it be better to be more selective when changing UID, if user have some folders where he act a another user, i.e root... something like:

Log out theuser and as root:
 usermod -u new_uid theuser     # new_uid >= 1000 and not taken...
 find /home/theuser -user old_uid -exec chown -h theuser {} \;

!!Big WARNING: Untested and I dont really master what i tried to write above!!
Morgan Leijström 2021-03-08 13:48:37 CET

Keywords: FOR_ERRATA8 => IN_ERRATA8

Comment 4 Morgan Leijström 2021-04-04 12:37:10 CEST
Thus bug will be a wontfix.

Would be good to have a manual procedure dercribed in errata.

So please some CLI wizard tell if my idea in comment 3 is OK ?
Comment 5 Dave Hodgins 2021-04-04 15:02:06 CEST
It's very risky. The user may have files stored in non-normal, or currently
non-accessible locations such as a currently unmounted usb drive (backups etc.),
or remotely mounted filesystem that root may not have access to.

There may also be applications that have stored the uid rather then a login
in a database or configuration file.

The people who have the id's under 1000 are people who have upgraded from prior
releases (or forced the id during install), which are also the people more
likely to have user owned files in non standard locations.

They are also the people more likely to be ok with having to add a script
to be executed by ~/.profile or ~/.bash_profile to add the games back for
their logins, or willing to take the risk of modifying /etc/limits.conf
to change the UID_MIN back to 500.

Following comment 1 will leave user owned file inaccessible in /var and
other locations.

I would not be comfortable with any script that tried to handle all of the
possibilities.

I agree that this should be closed as wontfix, but will leave it open for now,
for others to find so they understand why it's wontfix.

CC: (none) => davidwhodgins


Note You need to log in before you can comment on or make changes to this bug.