User not in wheel after install

Hi

I installed OpenSUSE Leap 42.1. During the installation I marked by user as being administrator. After boot
the user was not added to wheel which resulted in being prompted for root password for network connection, suspend,
etc.

Did anybody experience anything similar?

Stuff worked out perfectly after I added my user to wheel manually.

Bo

Totally do not understand??? The first user defaults to using the same password as root unless you giee root a different one. This does not make him/her administrator, which is a Windows term. You can boast a users permissions after install but they still are not root and is highly NOT recommended unless you really understand Linux extremely well. Even then it is not a great idea. And if you understood Linux you would not have to ask how to do this :open_mouth:

Linux is not BSD Unix,it has a different culture and expected behaviour. However we have been in the habit of creating admin users with lowish userids (so that they are hidden from graphical login screens), adding them to %wheel, and uncommenting the appropriate line with visudo.

Well. What a nice thing of me to sound as an absolute newbie with over than 15 years of unix experience. :slight_smile: What I meant was it seems like the polkit has dependencies on the wheel group for allowing some tasks to be run (maybe I read the configuration wrong). “Administrator” term probably come from ubuntu in this context (I think they call a guy that, that can sudo a command). I misread the installations instructions, I am aware now that the option let you set the same password for the root password (which is kinda stupid in my optics, why just not give that guy sudo access, but that is another discussion). Nevertheless there is something wrong that i am prompted for root password to connect to wireless network, suspend my computer, etc, but adding my user to “wheel” did the trick.

BTW I don’t like your tone, nobody wants to feel like they are a complete idiot, not even a newbie.

Bo

Not that I am aware of; but it definitely has dependency on allowing currently active users on local console much more than users in remote sessions or in background. It sounds like for some reason your session is not considered active. Someone reported similar problem recently. Check with loginctl which sessions are currently running and with “loginctl show-session session-number” whether your session has Active=yes and State=active.

Well I have no way of knowing your knowledge but what you want to do is not the recommended way of doing things.The Normal way is to become root via su/sudo or any other su variant. Having a normal user logged in with elevated permissions is just asking for problems security wise. But your machine run as you like.

I haven’t found anywhere that “wheel” does anything in opensuse. I know that Ubuntu uses that for its idea of an administrator. But opensuse really doesn’t use that concept.

I think you are suffering from a bug introduced in an update to polkit (version 0.113-6-1). With that bug, all is fine after reboot. But if you logout then login again, polkit doesn’t work properly and you get inappropriate prompts for root password.

I think (but I haven’t tested this extensively), that if you logout, and then wait 5 minutes before you login again, all will be okay. But if you logout then login immediately, you will have the problems you are describing. Hopefully this bug will be fixed soon.

Last I checked, the “wheel” user group exists in openSUSE but isn’t ordinarily used (or at least I haven’t seen for a long while).
I’ve used the wheel group as a super user group to enable apps/services to run using custom user accounts but with near-root permissions. IIRC the last time I configured was to provide the security context for a web-based CRM application.

I’ve <never> added an ordinary User with local login permissions to a wheel group, that to me would be a major security mistake.

TSU

I do not think that the OP intended that. This is a cultural misunderstanding – openSUSE is biased towards the personal computer, whereas Unix retains more of the feel of a multi-user/mainframe environment where there will be a team of system admins. The not unreasonable expectation is that the initial user would be an system administrator and not an ordinary user.

I would add the trusted system administrators as normal users, and then add them to %wheel. Wheel is then given permission in /etc/sudoers to run any command as root without a password (the pre-Leap openSUSE had this as commented example sudoers entry). The root password was then changed daily to a random string so as to frustrate guessing or brute–forcing. If anything untoward happened, we should maybe know which user login was responsible.

I’ve used the wheel group as a super user group to enable apps/services to run using custom user accounts but with near-root permissions

That is not in the spirit of %wheel. I would be unhappy about a third party CMS running anything as “root”. I, e.g., commonly made a “printman” group and used sudoers to allow %printman to run lpadmin based scripts. This allowed selected users in remote offices to be added to %printman and thus clear and restart local printer queues.

But then I am from the grumpy old man school of admins.

P.S. does anyone know what the “Multi-Quote This Message” option in this forum does? It’s next to “Reply With Quote”.

Whatever that “multi-quote” thing does, I’m trying it out now. Don’t notice anything different…

Thx for describing your own opinion about wheel!
The experience I described was based purely on the detailed instructions for setting up that app… not my own creation… And might be as much a product of that time when security was evaluated differently than today.

Your suggested use making ordinary Users members of the wheel group is an interesting attempt to fill a missing need (maybe flaw?) in *NIX security which IMO is based more on machine security and not User-based security (which is how MS Windows is fundamentally designed). I think though that other new and better systems to accomplish this objective have appeared (like AppArmor).

I’d be somewhat reluctant to base my security on something that had to change every day and the new setting would need to be propagated to all affected users secretly.

TSU

Try ticking multiple posts.

I thought that someone might know what “multi-quote” was, but maybe nobody does.

… and the new setting would need to be propagated to all affected users secretly.

The point of a randomll generated password (pwgen in a cron job) is that no-one knows the root password. The inclusion of

%wheel  ALL = (root) NOPASSWD:ALL

in* /etc/sudoers* means that any wheel member can execute commands as root (including* sudo su - *) without knowing any password/phrase other than their own.

Yes there are other more modern methods of managing user/operator permissions,but I learnt about wheel about thirty years ago, and I believe the concept predates Unix and Multics. The idea is that admins restrict themselves to their primary users group permissions unless they consciously invoke the wheel privileges via sudo. A useful side-effect of continuously changing the root password is that it mitigates against an admin setting a convenient password and inadvertently leaving it.

Thank you arvidjaar – that had been really annoying me or a while.

Heh.

I did not even notice that option at the bottom of the message window. When I looked for it after reading this, I did not spot it immediately, then I noticed the 2nd black Qoute icon to the right with a plus sign (+) beside it. When I hovered over it, the text “Multi-Quote …” et al popped up.lol!