Comment # 10 on bug 1228728 from Jiri Slaby
(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: