What is the correct behavior for the login screen?

Just installed Leap 15.6 over a just out-of-maintenance 15.5. I am using the KDE desktop. The basic install seems to have gone fine, but the login process seems changed. I am used to the behavior that if I logout of my basic user account (there is only that and root), I always get back the basic login screen where I can either login again as my usual user, or I can change to root. For a start, the icon/symbol that offers the choice of changing users is not constant. Sometimes it is Other, which is kind of a rectangular object, and sometimes it is the picture of two outlines, one male head, the other female, judging from the pony tail. I have not been able to determine the scheme for either option’s display on the screen. Only Other seems to be functional, in the sense that I can actually change users and login as root. On the other hand, if I have logged out as my basic user, then logged in as root, and then logged out of root, I get no login screen at all! Just black, with an arrow cursor, which can be moved by the mouse, but no user or password entry fields. At that point I can only hit the hardware reset button and do a reboot to get back to a useful login screen.

If this is older behavior, I haven’t detected it before. I don’t use root a lot, but have needed to after the install because I install MATLAB as root, and that is failing also…another problem altogether, not for this Forum.

On a default 15.6 KDE install I see the “Other…” option with two boxes mimicking input fields for username and password.
Logging out brings me to the login screen.
But you may have a different theme / branding package installed (coming from 15.5 maybe?).
That said, logging in a graphical session as superuser (AKA “root”) is never a good idea since graphical apps may access files that a “normal” user cannot touch and possibly change their permissions. I cannot tell if the apparently odd behaviour you witnessed might be related to that discouraged practice.

Are you logging in on the desktop as root? DON’T. It is creating a security hole and aside from that it CAN bork your desktop experience

Gentlemen, thank you both for your replies and warning! I am taking them both quite seriously. However, I confess that I am a little mystified why then , if being root in a GUI (or using a graphical editor to edit system files) creates such a security hole, does OpenSuSE allow graphical login to root? I realize the deprecation of the practice has certainly developed over time, but I cannot recall seeing any warnings about it. What about running (graphical) Yast2 ? Before the update paradigm changed (my failing memory does not remember when) one needed to login to root, and run Yast2 and choose Online Update to keep software packages current. That was an almost daily occurrence. And occasionally I did edit system files using Emacs. But no problems or warnings that I know of.

It looks like I need to re-install, but before I do, can you point me to SuSE literature or the like that describes the awfulness of being root in a GUI? I also need to understand the distinction between “Switch User” at the login screen (not quite the same as issuing su in a terminal window?) and “Other”.

Thank you.

The internet is rife with instructions to not login as root. Some distros would have you believe you cannot have a root login at all. It seems naive of you to not have encountered the concept before now.

Ability to login as root at a GUI login screen depends on the DM and its configuration. Other than with theming, openSUSE has a proclivity to accept whatever upstream’s default configuration happens to be, whatever the upstream may be. Some DM upstreams effectively make it impossible to login as root, at least by default. SDDM, the default for KDE installations, is one such. Others acknowledge who owns a computer, and/or the concept that whatever a superuser cannot do no other user can be expected to be able to do. Basically, whether you can or not on a fresh installation depends on your choice of DM, which in turn depends on your choice of DE or WM. Beyond that, it’s up to you to reconfigure if you don’t like the result.

I don’t take the paranoid position of so many others. My computers have hundreds of installations for test purposes only, most that I have, where I haven’t even created a regular user at all. Most of what they get used for requires superuser permission to do, thus making disabled root login for many activities a considerable functional impediment.

I am no security expert, so wait for others to chime in if you are looking for the details; nonetheless here is a little experiment to help you think again.
(Apologies for the long post, skip to the end if you are in a hurry :wink: )
Login as “normal user” in a graphical session, open a terminal, issue the following commands and watch the result.

bruno@LT-B:~> ls
bin                            Pictures
Desktop                        Public
Documents                      public_html
<snip>
bruno@LT-B:~>

That’s your /home/<username> folder, isn’t it?
Now:

bruno@LT-B:~> sudo ls
[sudo] password for root: 
bin                            Pictures
Desktop                        Public
Documents                      public_html
<snip>
bruno@LT-B:~>

Looks the same, or maybe not (colours to distinguish directories from files are gone?).
Now:

bruno@LT-B:~> su
Password: 
LT-B:/home/bruno # ls
.bash_history                       .nv
.bashrc                             .nvidia-settings-rc
bin                                 .openjfx
<snip>

You are still in your /home/<username> folder, but you are using some preferences of the superuser (on this system “ls” works as “ls --almost-all” for the superuser).
Now:

LT-B:/home/bruno # exit
exit
bruno@LT-B:~> su -
Password: 
LT-B:~ # ls
.bash_history            .bash_history-06001.tmp  .bash_history-26676.tmp  .gvfs           .xauthdb1qch
.bash_history-02375.tmp  .bash_history-06021.tmp  .bash_history-28492.tmp  .lesshst        .xautheqonxB
<snip>
LT-B:~ #

You are now in the /root/ folder and, most important, you completely changed the environment variables to those of the superuser, like if you were logged in as “root”, and you can do “everything that the superuser can do” but there is no graphical session linked to the superuser, no network access with superuser power etc., so your system is still “safe” (well, not protected from your own mistakes really :wink: ).
You have still another option to gain some superuser power, for instance to open a graphical editor:

bruno@LT-B:~> gnomesu gedit

(gnomesu:19933): Gtk-WARNING **: 19:27:05.721: gtk_window_set_titlebar() called on a realized window

(or the equivalent kdesu if you are using KDE).
All these methods imply various degrees of protection of the system; when you login as “root” in a desktop session, every application (and the DE itself) has superuser power and some may cause extensive damages since they were not designed with such use case in mind. Think of web browsers, every javascript on the net may take control of your entire system, for instance.
In the end, you have several “safe” ways to gain superuser power, if you still choose to login to a desktop as “root” I doubt that you have the knowledge and attention to do only those actions that really need superuser power and not cause non-repairable damages sooner or later.

Oooops.

Running openSUSE Leap 15.6 here (KDE Plasma), default install, and using SDDM (numerous machines).

I just now did a “Switch user”, and the SDDM graphic login screen was displayed.
I clicked on the “Other” choice, then typed “root” for the username, and entered the password for such, and voila, logged in.

Did I misunderstand something? I read “it’s impossible to log in using root account at the SDDM login screen”. Maybe openSUSE changed to allow it?

A Root gui can silently change user to root in your user home if you navigate there. Been there done that :dizzy_face:

Though I have no need to do so, my experience is that SDDM does allow root login to the Plasma KDE desktop (as you describe).

Once again, thanks to all for their contributions, warnings and suggestions in reply to my initial inquiry. I have re-installed 15.6 and, so far, the login screen weirdness has not reappeared. My initial inquiry related to the fact that such weirdness had never appeared before, even though I have definitely logged into root in the graphical interface many times over the years. Some of you may recall that the default background for the root GUI used to be an array of cartoon anarchist bombs, fuses sputtering, just to warn you where your were, and what power you possessed. I have never destroyed a system yet, although as investment prospectuses always warn “Past performance is no guarantee of future results…”

Thanks particularly to OrsoBruno for supplying the 4 examples. I get the point, but my use of sudo has been extremely limited over the years, and I have never issued a “sudo -” command. But perhaps your point is that I should be using it more, rather than acquiring the “unlimited cosmic power” of logging into root by the GUI. Something for me to reconsider!

Nice to see I got to the point, which was to show that there is a range of options to gain superuser power.
As I see it, sudo is a way for system administrators to give some, at times very limited power to “average users”, since it can be configured to allow only a limited range of commands.
Since you are apparently the sysadmin of your systems, no surprise that you seldom/never used it (me too :wink: ).
My favorite is su - and working with command line tools or occasionally invoking a GUI editor from there (gedit, kate …) which is way less invasive than logging in to a desktop as superuser.
Those who don’t love the CLI may use gnomesu <graphical app> (try also ALT+F2 to avoid opening a terminal), which is pretty safe if the app is a file manager or editor.

I tried sending this response privately to myswtest to avoid risk of going whatever the mods consider to be off-topic, but OP apparently does not accept private messages.

I don’t think a default openSUSE KDE installation keeps the upstream default theme. KDE theming has traditionally leaned to blues dominating, while Geckos are all about greens. :smile: Allowing root login may have been another change tagging along with the greens. I remember having a fit trying to enable root login with SDDM years ago, in the KDE4 or early KDE5 years, when SDDM was KDM slimmed down replacement wholly unsuited to my own unusual requirements. So on most installations, I reverted to KDM3, TDM or LightDM to avoid that obstacle. And, I mostly do upgrades, so am not very often exposed to what defaults may have changed. I installed Neon, the KDE up-to-the-minute flagship, a year or more ago. Last I remember trying, either I still hadn’t figured out how to login as root in SDDM, or couldn’t get the GUI screens to leave tty1-6 free for my use, so was running with it disabled:

  Desktop: KDE Plasma v: 6.2.4 tk: Qt v: N/A info: frameworks v: 6.8.0
    wm: kwin_x11 vt: 7 dm: 1: SDDM note: stopped 2: TDM 3: XDM
    Distro: KDE neon 24.04 6.2 base: Ubuntu 24.04 LTS Noble

I can’t remember how I’ve been starting GUI sessions there, and disappointingly, this inxi excerpt doesn’t really help. That was in December, so I don’t remember. Neon is just something I dabble with now and then. It’s a disk space hog, like its Ubuntu parent, except it’s rigged to make it difficult to purge apps I never try to open, or features I’d never have a use for on a testing-only PC.

It depends on the configured SDDM theme as to whether you can select “Other”, and also MinimumUid can be set explicitly so that only users with a UID greater or equal than that value will be displayed.

Until I locate a TW installation here that has Plasma6 and still has SDDM, I’m trying in a possibly borked Neon, which seems to have a mixture of 6.3.2 and 6.3.3:

# cat /etc/sddm.conf.d/u.conf
# /etc/sddm.conf.d/general.conf
[General]
InputMethod=
Numlock=on

[Users]
MinimumUid=0

[X11]
ServerArguments=-nolisten tcp -dpi 132

[XDisplay]
MinimumVT=7

Initially I was assuming this was resulting in default Breeze theme with a bazillion user icons to select from a horizontally scrolling list. Root login was rejected without explanation, just a shaking of the input fields…

# cat /etc/sddm.conf.d/u.conf
# /etc/sddm.conf.d/general.conf
[General]
InputMethod=
Numlock=on

[Theme]
Current=elarun

[Users]
MinimumUid=0

[X11]
ServerArguments=-nolisten tcp -dpi 132

[XDisplay]
MinimumVT=7

# systemctl restart sddm
changed absolutely nothing I can see. Switching back from SDDM to TDM allows to login root.

In all the above, only with TDM is/was NUM on. After sleep will look for a TW to do this with…
…OK, tried installing SDDM on host ga88x with Plasma6 already current on 20250328, but not able to start it from TDM (where all is X11-only AFAIK), only IceWM and TDE. On switching from TDM to SDDM, root login is accepted, but still X11 Plasma does as did with TDM, black screens with a mouse pointer is as far as it gets. And, SDDM uses whatever the theme that sprawls an monster icon for every potential user, putting root in the way way out beyond to scroll to. Applying MinimumUid=0 and MaximumUid=0 are obligatory to correct that issue, since there is no SDDM (as yet that I have discovered) option to define a userID range, or specify particular users to list on the login screen, as KDM4 had, and TDM and KDM3 provide. I fixed that switching theme to maldives, but X11 Plasma still won’t run. Wayland Plasma, X11 TDE and X11 IceWM all fully start NAICT.