Thomas M Steenholdt wrote:
Chris Adams wrote:
> Once upon a time, Behdad Esfahbod <behdad(a)behdad.org> said:
>> 3) Symlink all of a) into /bin (or symlink), but keep b) in /sbin and
>> keep /sbin out of users' path.
>>
>> In an ideal world, we would have 3. But it's a lot of packaging work.
>
> How much, really? There are maybe a couple of dozen commands in /sbin
> and /usr/sbin that are useful to non-root users, and many of them come
> from the same package. Many of them probably don't even need symlinks
> (who cares that lspci has moved for example).
>
> Now, I always just have PATH=$PATH:/usr/sbin:/sbin in the system profile
> on my systems (so I certainly don't object to doing that by default),
> but it would be better to do this the "right" way. The packaging
> guidelines going forward could then have something like:
>
> - /sbin: for administration tools only useful for root and needed to
> boot the system
>
> - /usr/sbin: for other administration tools only useful for root
>
+1 but I'd rather we did this the symlink way so we can identlfy a
command as an sbin command we have given regular users access to. In
most cases this will mean that the command may be run by a regular user,
but limited in functionality. (ifconfig won't set an IP address, only
show it, etc.)
Please, no. This is not a standard. Don't create it now.
yum, rpm, packagekit, yumex, apt-get, smart, mount, chown and all sorts
of other whatsit fall in this category. If you get nit-picky, kill,
chmod, cat, etc also have "limited functionality" for a normal user as
they only allow the normal user to operate on things for which they have
permissions/are the owner/ etc. The tools allow the superuser to
operate on the resource even if it doesn't belong to them or the
permissions explicitly disallow it.
-Toshio