Description of problem: During the upgrade process, adding a previously registered in upgrading user causes the users directories to belong to root. Version-Release number of selected component (if applicable): Mageia 4 RC 64 bits How reproducible: I don't know. Steps to Reproduce: 1. I upgraded from Mageia 3. At the "Summary" step, I clicked on "Manage users" and added myself, while I had already an account. 2. In logging in all user got a message saying that / was as user directory, and nothing else than a terminal was available. 3. In the said terminal, lauching "su" would answer "su: cannot set groups: Operation not permitted". 4. So I restarted again the computer, in safe mode and, as root, send "ll /home" and noticed that all the users' directories owner and group was "root". Expected: the "Manage users" step shouldn't be blind: we should be able to see the users, and adding an existing user shouldn't be allowed. Reproducible: Steps to Reproduce:
Summary: Adding a previously registered in upgrading user causes all the users directory to belong to root => Adding a previously registered user during upgrade causes all the users directory to belong to root
Sorry for the mistakes above. The description should be: "During the upgrade process, adding a previously registered user causes the users directories to belong to root." And the step 2: "In logging in all user got a message saying, if I remember well, that / will be used as user directory; and nothing else than a terminal was available."
Priority: Normal => release_blocker
Summary: Adding a previously registered user during upgrade causes all the users directory to belong to root => Adding a previously registered user during upgrade causes all the users directories to belong to root
Assignee: bugsquad => thierry.vignaud
Please attach your /root/Drakx/report.bug.xz
Keywords: (none) => NEEDINFO
Created attachment 4844 [details] /root/drakx/report.bug.xz
I guess this is linked with this bug: some setuid are not set correctly. For instance: $ chromium-browser [7132:7132:0123/140439:FATAL:zygote_host_impl_linux.cc(144)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /usr/lib64/chromium-browser/chrome-sandbox is owned by root and has mode 4755. Aborted # ls -l /usr/bin/pkexec -rwxr-xr-x 1 root root 24264 Oct 19 20:23 /usr/bin/pkexec*
Ah! The cause may be completely different: $ df Filesystem Size Used Avail Use% Mounted on /dev/sda1 12G 12G 48M 100% / So, to my mind, 1) these pages: https://wiki.mageia.org/en/Presentation_of_Mageia_for_beginners https://wiki.mageia.org/en/Mageia_4_RC should contain information about the required hard disk partitions (minimal installation, average installation), 2) the installer should check if it has enough room to upgrade Mageia 3 before trying it.
Thierry, don't we have such check in upgrade/install process?
CC: (none) => ennael1
The disk space option is unrelated. I can reproduce here with plenty free space.
CC: (none) => mageia
commit cfc5075fdd3effdb0617e98133cf08e6fbdceef7 Author: Colin Guthrie <colin@...> Date: Sat Jan 25 11:18:26 2014 +0000 Ensure uid/gid extraction works when adding users via summary page Fixes chown'ing user to root when adding existing user on upgrade. mga#12375 --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=cfc5075fdd3effdb0617e98133cf08e6fbdceef7
This should fix the issue. Need to test it, but the principle is valid and doing this manually confirms that the user is reported as already being present and it refuses to add it again. If it did add it, then the chowning stage would work properly too.
I wanted again to upgrade a PC from Mageia 3 to Mageia 4. Since it couldn't find the network, I opted for an full installation from a DVD, keeping the old partition, formatting / (root part) and keeping /home. I registered two users: myself, with the old characteristics, and another one called "precious-treasure". The latter SILENTLY failed, probably because "precious-treasure" is too long as a group name. Then again all the users directory belonged to "root", including mine, and I couldn't log in. If the registering username is the same as an existing home directory belonging to root, the installer should at least ask if that directory should belong to this new user and, if not, ask for the name of another home directory.
Again some setuid are not set correctly. For instance: /usr/bin/pkexec,/usr/bin/su, /usr/bin/sudo. And Mageia control center refuses to work (see attachment), as well as the package update icon in the tool bar (but urpmi --auto-update works).
Created attachment 5065 [details] Errors when launching DrakConf
Version: Cauldron => 4
The files marked "not executable" in the error messages are just absent...
'Needinfo'was fulfilled earlier. @all: please review, in particular as we have a new installer and pre-5 installer will not be fixed. I cannot judge if still valid. If so change headers accordingly. If not please close the bug report.
Keywords: NEEDINFO => (none)
CC'ing qa-bugs ml, hoping that, while iso-testing, someone will remember to test whether this got fixed
CC: (none) => marja11, qa-bugs
what about mga5 then ? Setting as release blocker for mga4 is useless...
Updated from Mageia4x64 (gnome) real hardware to Mageia5x64 using classical iso. Reproduced steps taken by Henri de Solages found in description (adding an already created user in Mageia 4 during install on Summary page). The bug did not occur for me, could log into user account normally, user directories permissions and ownership were correctly set. So it appears to me this bug is fixed for Mageia 5.
CC: (none) => olchal
Nice Olivier, this seems to confirm the fix by Colin linked in comment 8. Closing the bug then.
Resolution: (none) => FIXEDCC: (none) => remiStatus: NEW => RESOLVED
Thanks for the test. However, I'm not sure the test is 100% accurate. I'm not sure if the conditions reported by Henri were of an "Upgrade" per-se, but perhaps a wiping of / and keeping /home (i.e. total re-install) but "discovering" the users based on the name of their home directories left behind. Note that Henri specifies he formatted / and thus this was not an "upgrade". So further tests would still be appreciated to fully confirm.
I think that Henri followed 2 different procedures : - first one (in Description) : normal upgrade without formating / and adding user previously created during installation process. That's the one I followed and I did not encounter the bug he reported. - second procedure (in Comment 10) : full installation from DVD(formatting / partition) and keeping the home partition. That procedure I did not follow and cannot therefore tell if it is still problematic. I may be able to try it in the evening if I find the time.
I've a feeling this will still be valid, especially with the UID/GID changes in mga5. I have an mga4 snapshot in vbox so i'll try this today. re-opening until we know for sure
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Performed an installation rather than upgrade to an existing mga4 system using pre-release beta3 classic dvd 64. Formatted / and left /home intact and simply entered the username for the mga4 user during user configuration. No issues after installation, user still had uid/gid 500 and ownership in /home is as normal. Closing again as fixed.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED