[login fails] why setting user out of 'wheel' group blocks GUI login?

[Nixota]

Hello everyone,

trying to follow some of the suggestions for OpenBSD hardening at the link:
https://dataswamp.org/~solene/2023-1...ast_privileges

Initially, I took the current user off of the 'wheel' group, so that the user has no su -, nor doas abilities, but then - after rebooting - an unexpected situation:

it's impossible to login through the GUI using the usual 'username'/'password' because the system prompts:

Login incorrect or forbidden.

It's possible to login ONLY through the CLI - by accessing the terminal via ctrl+alt+F1...F8, in which case the 'username'/'password' get accepted without any issue.

How to regain access through the GUI/standard desktop environment? i.e.,
What to perform in the CLI in order to overcome the now missing 'wheel' group for the user?

Thank you in advance,

BR

[jmccue]

A wild guess, try adding your user to group "_x11". I think that is the group xenodm runs under.

[jggimi]

I would hope the error might be caught in logs. Check $HOME/.xsession-errors, and if necessary check /var/log/xenodm.log and /var/log/Xorg.0.log.


I can't reproduce the problem with a user who is not in the wheel group.

[Nixota]

Hello, so:

Originally Posted by jmccue

A wild guess, try adding your user to group "_x11". I think that is the group xenodm runs under.

Yes, the current user is granted _x11 group privileges, that was checked with:
$ cat /etc/group

nevertheless, still I can't login with the usual 'username/password' in GUI prompt.

Originally Posted by jggimi

I would hope the error might be caught in logs. Check $HOME/.xsession-errors, and if necessary check /var/log/xenodm.log and /var/log/Xorg.0.log.

After logging in as 'root' in CLI I checked all #3 files:
1. $HOME/.xsession-errors –> does not report any error
2. /var/log/xenodm.log -> outputs the following (head part with configs omitted):

Failed to create var/empty/.cache for shader cache (Permission denied)–––disabling
WARNING: Kernel has no file descriptor comparison support:No such file or directory
Failed to create /var/empty/.cache for shader cache (Permission denied)–––disabling
xenodm info (pid 41675): consolePath: ttyC4
xenodm info (pid 41675): sourcing /etc/X11/xenodm/Xsetup_0
(II) AIGLX: Suspending AIGLX clients for VT switch

3. /var/log/Xorg.0.log -> gives a long stack trace, but apparently no specific errors are reported. Note: the last line of the stack trace gives the same output about the AIGLX clients suspension.

Any clue?

BR

[jmccue]

Failed to create var/empty/.cache for shader cache (Permission denied)–––disabling

Very weird, I use cwm(1) and neither directory/file /var/empty/.cache nor ~/var/empty/.cache exists for me. My id is in the wheel group.

I doubt I can help further, but for others can you supply the Window Manager you are trying to use ?

Also can you test with twm(1) to see what happens ?

Good Luck

[jggimi]

/var/empty should never have anything in it, as it is a $HOME placeholder for daemons. I get the same warnings on my laptop, where I'm using i3wm with the picom compositor.

Create a new test user that doesn't have an .xsession/.xinitrc script. When logging in, you should end up with all the defaults: the fvwm window manager, an xterm, a clock, and an xconsole window.

If your new user logs in without a problem, you'll know the source of the problem is your .xsession script. If it fails to log in, you'll know the source will be something misconfigured in /etc/X11/.

[Nixota]

Hello and thank you for your suggestions:

dealing with:

Originally Posted by jmccue

Also can you test with twm(1) to see what happens ?

The window manager enabled on the OS here is cwm but I don't know how to switch to twm to test it.

Originally Posted by jggimi

If your new user logs in without a problem, you'll know the source of the problem is your .xsession script. If it fails to log in, you'll know the source will be something misconfigured in /etc/X11/.

This is the next thing I will try.

Recap:
1. the first thing I tried was to put back the current user into the wheel group. Outcome: still, cannot log in to desktop environment GUI.
2. could it be that the X11 misconfiguration problem was generated by the fact that I previously swapped the Caps Lock with the ESC key in the wsconsctl https://man.openbsd.org/wsconsctl.8 config? (I wrote a previous post here on Daemonforums: https://daemonforums.org/showthread.php?t=12515), and I changed the password to lowercase (so to avoid the use of Caps Lock when logging in)
3. I verified the .xsession script and it's very simple/minimalistic, if needed I can post it here
4. I checked the .xsession-errors file and it reports the following:

xrdb: No such file or directory
xrdb: can't open file 'home/[username]/.Xresources'
property 'WS Pointer Wheel Emulatin Axes' doesn't exist, you need to specify its type and format
XIO: fatal IO error 4 (Interrupted system call) on X server ":0"
after 501 requests (501 known processed) with 0 events remaining.

Last question: if fixing the glitch is too complicated, as a Hail Mary situation, what if I simply uninstall X11 and reinstall it? would that work/bypass the glitch?

BR

[jggimi]

Fatal error on a system call? /var/log/Xorg.0.log will likely have logged something helpful. Are you running -current? 7.4?

[Nixota]

Originally Posted by jggimi

Fatal error on a system call? /var/log/Xorg.0.log will likely have logged something helpful. Are you running -current? 7.4?

1. well, the /var/log/Xorg.0.log reports a rather long list... unfortunately, I have no idea what is the meaningful part of it in the actual context
2. sure, I'm running vs. 7.4

PS. though I created a copy - with $ cp -p .Xdefaults .Xresources of the .Xdefaults file, tried to set the .Xresources file available to the xrdb with $ xrdb ~/.Xresources - which, b.t.w. outputs the error:

xrdb: Can't open display ''

and verified that the /etc/hosts file reports the correct configuration for localhost, the situation hasn't changed a bit.

Still cannot log into the desktop environment.

BR

[Head_on_a_Stick]

Originally Posted by Nixota

the /var/log/Xorg.0.log reports a rather long list... unfortunately, I have no idea what is the meaningful part of it in the actual context

Show us all of it then.

This will upload the file to a pastebin site and return a URL that can be shared here:

curl -F 'file=@-' 0x0.st < /var/log/Xorg.0.log

[Nixota]

dear All,

first: thank you for your precious support!

As I previously guessed, I found the reason I couldn't log in via the desktop environment prompt: that was due because I previously swapped the 'Caps Lock' with the 'ESC' keys, i.e., in the /etc/wsconsctl.conf file I made the following setting:

# swap Caps Lock with Esc key
keyboard.map+="keysym Caps_Lock = Escape"

That config messed up the login process. Just commented out that line and everything is back to normal.

BR

[J65nko]

Typical case of PEBKAC (Problem Exists Between Keyboard And Chair)

[Onauk]

Originally Posted by Nixota

As I previously guessed, I found the reason I couldn't log in via the desktop environment prompt: that was due because I previously swapped the 'Caps Lock' with the 'ESC' keys

Is this expected behaviour? I mean, it sounds like Nixota was entering the wrong password because of the swapped keys but since they said their password is all lowercase, I really don't understand what could have caused this.

Arranging keys is quite important to my use of any OS since I need to enter a lot of accents so if OpenBSD doesn't support changing keys in wscons it sounds really bad.