Session login: various bugs

Hello,

I just created another user for the first time, for a friend to use my computer when she passes by my city. I noted several design & implementation bugs around users & sessions, on my system. I list them below either for developper feedback (I program myself) or to get suggestions for users (others & myself):

  • When creating a user, the password is not asked twice, so that we cannot know, I guess, what we have typed, actually (LXQt design bug, it seems).
  • This bug seems eternal, just got a random appearance variant: at session login or change, numlock seems randomly lit; in ancient times it was always off; this despite being “on” in BIOS (I rechecked). Even when lit, it is not taken into account: I need to manually switch it off and on again (there are digits in some password). I know there are workarounds (with keyboardx); it is not what I am looking for: ordinary users should have it right.
  • Also, the LXQt keyboard parameter “turn on numlock after login” (note “after”) does not seem to do anything: it is always on (and the setting was unchecked by default by me!).
  • The session login only proposes as keyboard type “US”, or rather it pretends to do so. Well, annoying. And wrong: this not my keyboard type and it works fine (in some password there are characters which are on different keys from US keyboards). PS: once, when changing session, the proposed keyboard type was my own: thus this bug also looks random.
  • The other user can access my /home! She can even open and read documents… Conversely, I can access her data. All what seems blocked is changing documents (“permission denied” on save, as for changing system data without sudo).
  • Under my own user identity, I can change the other user’s password! (A husband could block his wife: no comment.)
  • The sound is off after session change… I have to reboot to get it back. Ggrrr!

Thank you!

At the end of the post you mention sound problems, I have a couple of boxes that often ‘wake’ from suspend without sound; I can usually fix it by going into pavucontrol (pulse audio volume control) and clicking the Profile off & on again; so I suggest you try it.

You didn’t specify what release of Lubuntu you are talking about, I’ll test what you’re describing using Lubuntu 20.04 as a i have a ~new install besides me.

Using “User and Group Settings” I created a new user “Blah” (I added them to sudo group, I trust ‘blah’).

Yes I was only asked to enter the password once.

I logged out (as me). (UID=1000, GID=1001)

I logged in as ‘blah’. UID=1001,GID=1002

Yes I could cd and read files owned by ‘guiverc’, due to the UID (1001) being the GID (GroupID) of ‘guiverc’.

I’ll have to look at this more, and see if a bug has been filed (tomorrow, I’m too tired tonight), however if you’ve done it - please provide launchpad bug reference (and your release please).

FYI: In the past UID & GID used to be the same value (thus the new user of 1001 was fine). I’ll also do the same thing in Debian Bullseye/11 (LXQt) tomorrow to see if it’s any different there, or it’s only a Lubuntu issue (if it’s us only, I’ll contrast with Xubuntu…)

Note to self: My primary box has UID=1000, GID=1000, it must have changed after I installed on this box

On debian bullseye/sid, my username (guiverc) is 1000/1000 (user/group ID), a newly created user ‘blah’ was 1001/1001 looking at /etc/passwd.

I logged in (text tty) into ‘blah’ and could READ my /home/guiverc/ files, but had no write access.

Permissions by default allow for this, as files created by ‘guiverc’ are given 644 (read for everyone) by default, the account ‘blah’ could NOT create or rm files in /home/guiverc

This test is a base-line as I see it; if Lubuntu acts like this it’s probably needs to be worked around by changing default permissions on creation; not forgetting R access to directories…)

I went back to the Lubuntu 20.04 box I used in prior comment (near fresh install; dc7700) and results were identical.

What stood out though was the 1000/1001 [Uid/Gid] for ‘guiverc’ & 1001/1002 [Uid/Gid] for ‘blah’ which I will explore further as that is what stood out as wrong (to me) in my last comment…

When I do the same on my primary Lubuntu 20.04 box (but heavily modified) a created user ‘blah’ has 1001/1001 just as with debian; and my ‘guiverc’ is 1000/1000.

guiverc@d960-ubu2:/sbin$  egrep 'guiverc|blah' /etc/passwd
guiverc:x:1000:1000:chris guiver,,,:/home/guiverc:/bin/bash
blah:x:1001:1001:blah:/home/blah:/bin/sh

Using the current Xubuntu 20.04 daily (20191213); the default ‘xubuntu’ user is 999/999 (uid/gid). A created user ‘blah’ is 1000/1000. I don’t know if it’d be different when installed. Xubuntu did need the password for new user to be entered twice.

I booted a Lubuntu 18.10 (x86) system (fully upgraded as it reached EOL, but unclean as had xubuntu-desktop installed) and created user ‘blah’. My ‘guiverc’ was 1000/1000, ‘blah’ was 1001/1001.

I booted a Lubuntu 19.04 (x86) system, and it already had two users; egrep 'guiverc|testing' /passwd showed ‘guiverc’ 1000/1000 & ‘testing’ 1001/1002 it looks like I created that account 10-Aug-2019. I created a ‘blah’ account anyway and it was 1002/1003.

For no reason other than I like providing links :
https://help.ubuntu.com/community/FilePermissions
https://help.ubuntu.com/community/FilePermissionsACLs

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.