https://bugzilla.suse.com/show_bug.cgi?id=1228728 https://bugzilla.suse.com/show_bug.cgi?id=1228728#c10 --- Comment #10 from Jiri Slaby <jslaby@suse.com> --- (In reply to Björn Bidar from comment #9)

(In reply to Jiri Slaby from comment #8)

...

(In reply to Jan Engelhardt from comment #7)

...

systemd: stop using sbin me: you know what, I'm going to use it even harder

Exactly. They _always_ know what is the best for me. Mostly, they are wrong.

...

I'm with Thorsten on this one, less clutter please. About 17% of the stuff in /usr/sbin is daemons anyway which could eventually move to /usr/libexec.

OTOH there are entries like sysctl (checking mostly kernel.core_pattern) and mkfs/fsck (creating/checking a FS in a file) which I have no idea why are not accessible to a user. Every time, I have to prepend /sbin/ to call them.

Can regular users touch block devices?

Why do you think I explicitly mentioned files? Not only a bdev can contain a FS. As for VMs.

I could see why a user would require sysctl's but there's nothing they can do about it unless they also have root access which negates the reason to call sysctls as user.

Think more about "checking mostly kernel.core_pattern". Many of sysctls are useful as read-only. And for that purpose, most of them are readable by a user.

...

Then, there are utils which already have to have: /usr/bin/tcpdump -> ../sbin/tcpdump /usr/bin/ip -> ../sbin/ip

So it's all mess -- both one way and the other.

Again do this fully work as regular user?

Of course. You can dump saved pcaps from the same or another box for example. And I of course use ip to find out IPs. And link state, stats etc. It all works, was designed as such and belongs to /bin/ and not /sbin/. -- You are receiving this mail because: You are on the CC list for the bug.