LM8 Gnome: Standard user missing elevated group permissions

[OS2-User]

After some weird GUI freeze-up the other day, which required power-cycling to reboot, LM 8 Helena Gnome now gets stuck after switching to GUI mode with the small spinning wheel, right before the XFCE log-in screen is supposed to appear.

Back then a few years past:
Due to Gnome power management issues, I added XFCE back in the day to use its version, but came to miss too many Desktop features compared to Gnome to stay with the XFCE desktop. So after a little while, I switched back to the Gnome Desktop, yet kept the XFCE power and also the network manager, since they often worked more reliable than Gnome's.
But in the process, I got stuck with XFCE's blue mouse log-in screen and the Gnome session manager not working anymore.

Now and here again:
Log-in as root in a console works as usual.
Log-in from a console as the regular user works now only partially (see attached screenshot).

LM08_GroupPerm_2015-02-13_23-40-34.jpg

Apparently the user's group permissions for root owned executables and directories are not being issued, so nothing that is owned by root (like i.e. /usr/bin/env, cal, lsusb or bc) can be accessed or executed. However, 'echo $PATH' shows that path is set correctly and works for the user's own files and executables.

Since I don't know about the inner workings of the log-in and start-up process, there might now a needed config file now be missing or corrupted somewhere.

Sifting through dmesg and the most recent log files in /var/log/ I didn't come across anything that jumped right at me, but then again, I don't really know what exactly I would have to be looking for, if there actually would be any record of my current problem being recorded.

- How can I start the Gnome desktop from there and work as the now defunct user?
- Is it possible, to fix or recreate the current user account log-in data without damaging/deleting its existing files and settings, to see, if that would fix things?
- If not, what do I have to look into, to find out why the user account doesn't get those elevated group privileges for root owned files any longer?

Please be detailed and provide step by step instructions for where to go and what to do.

[Edit: forgot to upload the screenshot]

[austin.texas]

The first consideration would be to backup up everything, before altering user configuration.
Your user should be a member of the sudo group. To check, run the command:

Code: Select all

groups

[OS2-User]

Your user should be a member of the sudo group. To check, run the command:

Code: Select all

groups

Thank you. If he isn't, how do I add him from a root console?
What other groups would he have to be a default member of?

[austin.texas]

When you are logged in as root, you should be able to enter the command:

Code: Select all

usermod -aG sudo wolfi

to add the sudo group to user wolfi

[OS2-User]

Thanks a lot
I'll give it a try as soon as I am back home again from my current stint to the library.
Where would that new group membership info then be stored?
Is it just one file for each user or more like a centralized database for all users? (just trying to learn a bit here as well )

[OS2-User]

As it turns out, the problem unfortunately is a bit more complicated.
Apparently all the required file entries and permissions exist. For whatever reason, they just aren't applied to the standard user anymore and that is what I need to find out and fix.

- So, who can tell me how the boot process works and when and how those elevated "admin" group privileges are being assigned to the regular user account?
- How can I start the GUI from a root console. "start x" doesn't work.

This is what I found out so far:

# adduser newuser ==> Reboot ==> results in same problems as existing standard user 'wolfi' (missing root privileges).
To me that would indicate, that the problem is not with the existing user account 'wolfi', but with the mechanism, those elevated group privileges need to be assigned to the current non-root user.

Below are records from some files, while googling around for quite some time, have been pointed out to be relevant for the permission management:

Code: Select all

$ less /etc/group|grep -i wolfi ==> adm:x:4:wolfi
	    	    				    	   dialout:x:20:wolfi
	    	    				    	   cdrom:x:24:wolfi
	    	    				    	   plugdev:x:46:wolfi
			    	    		    	   lpadmin:x:104:wolfi
			    	    		    	   admin:x:115:wolfi          <===
			    	    		    	   sambashare:x:120:wolfi
	    	    				    	   wolfi:x:1000

Code: Select all

# less /etc/sudoers  ==> Defaults        env_reset
								# User privilege specification
								root    ALL=(ALL:ALL) ALL
								# Members of the admin group may gain root privileges
								%admin ALL=(ALL) ALL          <===

Code: Select all

# less /etc/shadow  ==> "root" and "wolfi" entries of same pattern do exist

Code: Select all

$ less /etc/passwd|grep -i wolfi ==> wolfi:x:1000:1000:WR,,,:/home/wolfi:/bin/bash

'echo $PATH' shows that path is set correctly and works for the user's own files and executables.
As far as I can tell, all that should be there, does exist, but doesn't seem to get processed at all.

- So, who can tell me how the boot process works and when and how those elevated "admin" group privileges are being assigned to the regular user account?

- Am I wrong to assume, that what happens on the console at log-in is independent from what the GUI is doing (or not doing) after switching from the text-mode boot message output screen on console one, to the graphics screen on console 7 or 8?

- How can I start the GUI from a root console? "start x" doesn't work.

[austin.texas]

As it turns out, the problem unfortunately is a bit more complicated.
Apparently all the required file entries and permissions exist.

Code: Select all

$ less /etc/group|grep -i wolfi ==> adm:x:4:wolfi
	    	    				    	   dialout:x:20:wolfi
	    	    				    	   cdrom:x:24:wolfi
	    	    				    	   plugdev:x:46:wolfi
			    	    		    	   lpadmin:x:104:wolfi
			    	    		    	   admin:x:115:wolfi          <===
			    	    		    	   sambashare:x:120:wolfi
	    	    				    	   wolfi:x:1000

No, they don't. wolfi is not a member of the sudo group yet. You can see that sudo is not listed. Did you log in as root (su) and enter the command: usermod -aG sudo wolfi ?

- So, who can tell me how the boot process works and when and how those elevated "admin" group privileges are being assigned to the regular user account?

I don't have a clue, and I don't think it matters.

- How can I start the GUI from a root console. "start x" doesn't work.

The command is not "start x", it is "startx"

# adduser newuser ==> Reboot ==> results in same problems as existing standard user 'wolfi' (missing root privileges).

Did you log in as root (su) and enter the command: usermod -aG sudo newuser ?

[OS2-User]

wolfi is not a member of the sudo group yet. You can see that sudo is not listed. Did you log in as root (su) and enter the command: usermod -aG sudo wolfi ?

Based on the info that I found while googling around for more info, the 'sudo' group is only being used with Ubuntu/Mint 12.04 and later, while before it is the 'admin' group. Just as found here.

As for your other suggestions, just to make sure, I have to check again once I am back home. I'll report back the results tomorrow.

[Addendum Feb 18th:]
When creating the 'newuser' account, for all I can tell, it gets awarded the same respective settings as the 'wolfi' account, but also fails to be able to exercise those elevated 'admin' group privileges for root-owned files.

I actually used 'startx', but mistyped it in my post. Sorry about that.
Anyway, using 'startx' from the root console results in:

"Fatal server error: server is already in use for display 0.
.............
xinit: Server error."

Doesn't the X11 system take care of the whole display stuff, including the console?
I may be wrong, but isn't it gdm or mdm, that is providing the graphical desktop and that I then should focus on instead of X, in order to get the GUI started from the root console?