A Fedora user rants about openSUSE : the root "Dictator"

English Soapbox
#1

**Context :
**
I’m a Fedora user, I tried openSUSE in order to help hunting the remaining bugs. I admit being now accustomed to the Fedora way of doing things, and admit that openSUSE folk may have another way of thinking than ours. Still, there a thing that I find very… questionable.
**
The root “Dictator”
**
In openSUSE, the “sudo” command seem to do the same as “su”. Why ? It’s dumb. because of that, I cannot give limited rights to a user.

I want to make a friend, let’s call him A, able to use some commands requiring to be super-user, but not other, on his own user account. I just cannot. Because of this **** sudoer file. Why? Here is the default openSUSE sudo configuration :


## In the default (unconfigured) configuration, sudo asks for the root password.
## This allows use of an ordinary user account for administration of a freshly
## installed system. When configuring sudo, delete the two
## following lines:
Defaults targetpw   # ask for the password of the target user i.e. root
ALL    ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

No, you aren’t dreaming, we are still using sudo “unconfigured” configuration. The only way to give to “A” sudo rights without manually edit the sudoer file is to give him the root password, thus giving him unlimited power on the system. If he do something bad (let’s say involving something similar to “sudo rm -rf /*”), there is no way to prevent damages. All I will be able to do is a rollback >:(… If the snapshots are still usable:.
To make it possible to give limited rights, I have to manually edit the suoer file via command line (like a lot of people I hate command line>:(). Yeah, yeah, I hear you YAsT guy, I know there is a sudo configuration gui in YAsT… But it is useless.
Without being able to remove the “Defaults targetpw” from the sudoer file, all change are just… ignored by sudo. Congratulation, you probably wasted you time creating an useless gui rotfl!.

The fix is rather easy : change

ALL    ALL=(ALL) ALL

to

%wheel    ALL=(ALL) ALL

and remove

Defaults  targetpw

.

With that, we have a working way to give users root right (by adding them to the “wheel” group), while not having to give them the real root password. Moreover, you can give to groups and/or users limited sudo rights.

Same goes for YAsT, that just ask for root password, regardless for the sudoer file.

#2

In Fedora this is already all set up like this, or do you need to perform any tweaks to do this?

does your selection during installation on the user effect this at all?

#3

Here is the default sudoer file from Fedora :

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
## 
## This file must be edited with the 'visudo' command.

## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using 
## wildcards for entire domains) or IP addresses instead.
# Host_Alias     FILESERVERS = fs1, fs2
# Host_Alias     MAILSERVERS = smtp, smtp2

## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname 
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem


## Command Aliases
## These are groups of related commands...

## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool

## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig

## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb

## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp 

## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe

# Defaults specification

#
# Refuse to run if unable to disable echo on the tty.
#
Defaults    visiblepw

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

## Next comes the main part: which users can run what software on 
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##     user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere 
root    ALL=(ALL)     ALL

## Allows members of the 'sys' group to run networking, software, 
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel    ALL=(ALL)    ALL

## Same thing without a password
# %wheel    ALL=(ALL)    NOPASSWD: ALL

## Allows members of the users group to mount and unmount the 
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

CU;DR (can’t understand; didn’t read):
-> The wheel group (the standard “administrator” group) have the right to run all command, but have to enter their password when needed
-> root can do anything, without needing to enter any password.

-> There is a bunch of commented example of sudoers permission, like allowing users to shutdown the system, to mount/unmount as root, some example of how to give limited root power (the “sys” group is allowed to use rpm/up2date/yum, and some networking/system command)

#4

On Thu, 05 Nov 2015 19:06:01 +0000, Dremor wrote:

> -> The wheel group (the standard “administrator” group) have the right
> to run all command, but have to enter their password when needed -> root
> can do anything, without needing to enter any password.
>
> -> There is a bunch of commented example of sudoers permission, like
> allowing users to shutdown the system, to mount/unmount as root, some
> example of how to give limited root power (the “sys” group is allowed to
> use rpm/up2date/yum, and some networking/system command)

That’s fine - Fedora has one way of doing things, openSUSE has another.

If you think the openSUSE behaviour is incorrect, I would suggest
submitting a bug in bugzilla. Personally, I don’t have a problem with it,
but I tend to be the only user on my systems, so I don’t care which
password I enter. I can see that in a multiuser environment, though,
that behaviour might be undesirable - in which case, it’s not a huge deal
to change it to what works for a multiuser environment. :slight_smile:

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

#5

A democracy is per definition forced to tolerate personal opinions. The UNO Human Rights Convention demands freedom of speech.
And now a little bit of philosophy – from the land of the poets and thinkers . . . :wink:

On the planet earth there are human beings which differ from the other animals on that planet in that they use tools.See material related to the Olduvai gorge in northern Tanzania or, “The Olduvai Imperative” ISBN 0-13-220104-6 Prentice Hall.

A CLI is a tool, a very sharp tool (you can easily cut your fingers) and, as with most tools it has to be learnt – apprentice/master relationship.Here in Germany, an apprentice sent an insult via SMS to his master. The apprentice was fired and he prosecuted. The court ruled that a vocational master has the obligation to not only give schooling in the trade, but also to educate the apprentices in good manners . . . :slight_smile:

One must use the CLI tool ‘visudo’ to edit the sudoers file (even on Fedora systems) and, there’s no universal sudoers solution – for any given system the administrators have to get in there and edit the rules for their environment.

It’s actually quite easy: RTFM! [Actually a BSD man page.] :wink:


> man sudoers
SUDOERS(5)                                     BSD File Formats Manual                                     SUDOERS(5)

And then, search for “EXAMPLES” – use the vi command ‘/EXAMPLES’ . . . ( “Scheiß CLI!!” – please excuse my German . . . )
You will notice there examples such as:


     operator        ALL = DUMPS, KILL, SHUTDOWN, HALT, REBOOT, PRINTING,\
                     sudoedit /etc/printcap, /usr/oper/bin/

     The operator user may run commands limited to simple maintenance.  Here, those are commands related to backups,
     killing processes, the printing system, shutting down the system, and any commands in the directory
     /usr/oper/bin/.  Note that one command in the DUMPS Cmnd_Alias includes a sha224 digest,
     /home/operator/bin/start_backups.  This is because the directory containing the script is writable by the opera-
     tor user.  If the script is modified (resulting in a digest mismatch) it will no longer be possible to run it
     via sudo.

     joe             ALL = /usr/bin/su operator

     The user joe may only su(1) to operator.

P.S.: Only robots are perfect – see Isaac Asimov’s “Three Laws” . . .
P.P.S.: Human beings produce errors – nobody’s perfect – because robots are perfect, only robots will be able to produce error-free code – unfortunately human beings will never be able error-free code, including the code which the robots execute . . . >:)

#6

Exactly, that why I give to the openSUSE community my opinion;). I’m currently using my own openSUSE-based distro, with Fedora based configuration (because of the problem I’m talking about, and some other similar problem).

Well, my point is that someone that don’t like/understand commandline (a “lambda user”) won’t be able to do it. Moreover, what the point of creating a gui in order to change the sudo configuration if these modification are ignored ? That ridiculous rotfl!.

Don’t forget, “RTFM” is used by people that forget that a good OS need to be understandable by everyday people. If a “lambda user” need to open a manual to understand the OS, then we are doing it wrong.

#7

Dremor, I hope that by “lambda user” you’re not meaning a person with tactile disabilities – yes, they will have more than a few issues with a CLI.Blind people on the other hand are more than happy with Braille keyboards and CLI – a GUI for them is a contradiction in terms . . .

If by “lambda person” you’re meaning a “new generation” user – someone who never ever used a (typewriter) keyboard – then you’re correct.With Touch-Screens – Tablets – Smart-Phones – this user-base is present and growing – fast . . .
[INDENT=2]** Principally Dremor is not way out-of-line with the issue he’s raised here. **
[/INDENT]

And, given a modern machine without a keyboard and, a new-generation administration staff who are also not schooled to type with a keyboard, Dremor has raised a valid issue here.How does one administer things which need the sudoer mechanism on a collection of the newest generation of machines (without keyboards)?

I can only suggest that the “sudoers” files are edited somewhere else using a “traditional” machine and then transferred to the new-generation machines – until such time as another solution is implemented:Possibly the GUI-World (KDE, GNOME, et al) could consider the development of a Plasmoid/Widget/Mini-Program to handle the sudo administration (without a keyboard).

#8

… actually, we long-time visitors to this forum find the “RTFM” reply unacceptable, even with a smiley. It is one of the main reasons we use openSUSE and why we are at the openSUSE forums.

#9

Point taken – I’ve replied to Gerry and asked one of the Moderators if it is possible to change the offending text.

#10

Despite my faux pas below, I suggest that we consider Dremor’s issue in another light:
[ul]
[li]Given this Forum and the title text of this issue, is Dremor simply “letting off steam” to relieve some frustration? [/li][li]Or, does Dremor have a point which should be worked through? [/li][/ul]

My two pennies are placed on the view that Dremor does have a point but,
[ul]
[li]A consensus should be reached on the definition of a “lambda user”. [/li][/ul]

Or to put it another way:
[ul]
[li]Is YaST usable on a Touch-Screen/Tablet/Smart-Phone?[/li][LIST]
[li]I can’t personally specifically answer because, our only Touch-Screen machine is an Android Hybrid-Tablet which is not available for non-Google experimentation. [/li][/ul]

[li]And, even if YaST is usable on such machines, given YaST’s root dependencies is something else needed to address the needs of administrating the list of “sudo” users within a group of “newest generation” users? [/li][/LIST]

#11

On 2015-11-06, Dremor <Dremor@no-mx.forums.microfocus.com> wrote:
> Don’t forget, “RTFM” is used by people that forget that a good OS need
> to be understandable by everyday people.

This is simply not true. Everyday people don’t use GNU/Linux let alone command line. On a number of GNU/Linux boxes, I
don’t even have sudo installed since it does not need to be an integral part of the GNU/Linux OS.

#12

I’m multi-user but am in what I consider to be a friendly environment. The other 3 potential users are my 80 year old parents and visiting family who I allow to log on to one of the PCs as user guest with password guest. The guest login does (via network manager) use a different subnet (Internet and the printer in the study only sort of thing) but that’s as far as I go.

With an OpenSuse install, I uncheck a box and go the separate password for root way. I don’t like the sudo way as I’d feel obliged to give myself a password more complicated than jonboy and (as I do on a raspberry pi be doing) sudo su…

Maybe I’m way too lax but I only feel a need to guard against people accidentally getting where they shouldn’t be. If my parents or say my brother are going to hack the setup by trying to log in as other people, I’ve got a problem far greater than a software one.