Thomas M Steenholdt wrote:
Chris Adams wrote:Once upon a time, Behdad Esfahbod <behdad@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
