In Leap 16.0 first user gets admin rights unconditionally

English Install/Boot/Login
1

In Leap 15.6 with KDE 5.27 I have this rights for ordinary user which I create during installation:

:~> groups
users

In Leap 16.0 with KDE 6.4 I have:

:~> groups
nameofauser wheel

, where nameofauser is user’s name.

In Leap 15.6 I have two distinct users: one for ordinary usage with minimal privileges and one root with full privileges.
But what is going on with Leap 16.0? IMHO this is a blunder :rage:

And I can get info about groups/rights in Leap 16.0 only with command prompt commands because YaST is no longer available.

2

I assume you mean after a fresh install. I doubt that will be the case after an upgrade from Leap 15.6.

You are not alone here.

I assume the only thing is to alter that to your liking (the old behaviour) using an editor on /etc/passwd and /etc/group. Or Cockpit.

I do not know if it is possible to do this already at installation. Reading the several topics about the new installation procedure here, I get the understanding that many deviations from it’s default actions are possible, but not easy to find.

3

Use cockpit.

4

Leap 16.0 is now using the same as other Distributuion using for years.

5

I was one of my reasons to go for SUSE years ago.

6

Upgrade to Leap 15.6 from previous Leap installations.

7

Unfortunately, this is intentional and completely incomprehensible to me.
It also annoys me. On the one hand, it cannot be used in a production environment because normally every employee has admin rights. Unless you give everyone their own user account. But then you need a new group, which already existed. And anyone who has been in production knows what that means and what happens.
On the other hand, I feel that this removes a level of security.

However, you can undo this. Either by using my package openSUSE-Leap-branding-ecsos. But this changes/fits a little more.

Or you can do the following:

_# Generate new/old rights for sudoers
cat > ecsos-sudoers << EOF
_# This will activate and rollback to the default UserRights
_# as we knew them until Leap 15.6.
Defaults targetpw
ALL ALL = (ALL) ALL
EOF
install -Dm 0644 ecsos-sudoers %{buildroot}%{_sysconfdir}/sudoers.d/ecsos-sudoers

_# Generate old login.defs, so user group is users again.
cat > ecsos-login.defs << EOF
_# This will activate and rollback to the default USERGROUPS_ENAB = no
_# and thus, a user once again receives the group = user and not the user group = username.
USERGROUPS_ENAB = no
EOF
install -Dm 0644 ecsos-login.defs %{buildroot}%{_sysconfdir}/login.defs.d/ecsos-login.defs

8

@ecsos ,
Can you please use the Preformatted text button </> when posting code?

9

Sorry, next time i will do it.
Unfortunately, I can’t do it anymore. :frowning:

10

for me editing groups wit cockpit didn’t worked so
I used systemsettings to do a new user=chief with root password and administrator level and I was able to switch the user as standard user so when user wants to do administrative things root parrword is asked, like the old behaviour

11

I think you made it even worse then it was.

12

One of the changes I made following my upgrade from Leap 15.6 to Leap 16.0 was as follows:

  • Take notice of the current Linux Standard and, the “useradd” man page –

By default, a group will also be created for the new user (see -g, -N, -U, and USERGROUPS_ENAB).

Please note that, I have User Groups as sub-directories of each “home” partition on this machine –

  • An example is in the SELinux “semanage-fcontext” man page:
   For home directories under top level directory, for example /disk6/home,
   execute the following commands.
   # semanage fcontext -a -t home_root_t "/disk6"
   # semanage fcontext -a -e /home /disk6/home
   # restorecon -R -v /disk6

Taking the example of the user I use for the management of my analogue and digital photographs –

 > grep -i 'bilder' /etc/group /etc/passwd
/etc/group:bilder:x:30500:bilder,bilder01,xxx
/etc/group:bilder01:x:30501:bilder01
/etc/passwd:bilder:x:30500:30500:Verzeichnisse für Bilder:/home01/Bilder:/usr/sbin/nologin
/etc/passwd:bilder01:x:30501:30501:Bilder verarbeiten:/home01/Bilder/bilder01:/bin/bash
 >

And, for completeness, an excerpt of my SELinux context equivalence is as follows:

 # LANG=C semanage fcontext -C -l
SELinux fcontext                                   type               Context

/home01                                            all files          system_u:object_r:home_root_t:s0 
/home01/KVM                                        all files          system_u:object_r:virt_var_lib_t:s0 

SELinux Local fcontext Equivalence 

/home/Users = /home
 . 
 . 
/home01/Bilder = /home
/home01/Test-VM = /home
 . 
 . 
/home01/User-VMs = /home/Users
 . 
 . 
/home01/KVM/images = /var/lib/libvirt/images
 #

I’ve moved away from Oracle’s VirtualBox for VMs – no Windows 11 license – no need …
But, KVM wants to place the VMs in my “/var” partition which isn’t large enough – therefore the move to a partition with sufficient capacity – and, with the appropriate SELinux context settings …

13

:grinning: why??

14

This has been standard on almost every distro for many years now. It’s also default for Windows and macOS. The person installing the device is, rightly, assumed to be the administrator of the device.

If you were handing out an installation disk to employees to install their own device and thinking they weren’t going to be the administrator of the box that is a you problem as you are not managing your fleet in the first place.

16

That is what is called a sane default. The person installing the device is the administrator.

And it did also always work that way, just with an extra step. The person who installed the device was also the person who picked the root password. The person installing the device was always the administrator unless some extra steps were taken.

Yes that’s right only you know how things work, yet you can’t figure out how to manage things. I come from production environments that have little things called central user management and configuration management, maybe you should look into them.

17

That was also one of the reasons decades ago.

18

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