In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, frwarner wrote:
>Yes, I understand that the binary must be in the PATH and of course be
>readable;
Actually, neither is true. If the binary is not in the PATH, you can
still run it by supplying the full path in the command. This is why
you often see a user running '/sbin/ifconfig' which works perfectly
well. As for the file being readable,
[compton ~]$ ls -l /bin/sudo
---s--x--x 1 root root 46080 May 6 2004 /bin/sudo
[compton ~]$
binaries don't have to be readable, they need only be executable. A
shell script on the other hand does need to be both readable and
executable to run
>But there's also another, more subtle and tricky problem: some programs
>just don't work for some users. E.g. several programs run only as root;
>everyone else may well be able to run the binary, and it will start, but
>not work.
Yes, there are a number of binaries that only root can run, even if
the user has execute permission.
>Typical example: mount/umount; the info who can use it is not in the
>filesystem (rx permissions for everyone) but someplace else (/etc/fstab
>in this case). And I don't know a general way of finding that "someplace
>else". Do you?
You hit one of the good ones - did you check the man page? In the case
of mount (and umount), it's mentioned in there. Generally, when you
are dealing with hardware (the disk for example, or the network), or
places where the command will impact other users, you need to be
super-user, or root needs to have done something to allow users to do
things. I'm thinking this is covered in at least two of the LDP guides
(
http://tldp.org/guides.html) - though I don't have them on this system.
>And if the decision is based on group permissions the filesystem, it is
>not clear which group is relevant. Half of the group names in
>/etc/group are not self explaining.
A lot of the groups are there for "traditional" reasons, as well as
file ownership. You could make all files owned by root, but there are
some that need _slightly_ elevated permissions, but not everything. Try
this:
for GROUP in `cut -d: -f1 < /etc/group | grep -v root`
do
find / -group $GROUP -exec ls -lad {} \; >> /tmp/group.ownership
done
These four lines are meant to be run as a shell script. You can also
run this manually - one group at a time from the command line as in
find / -group admin -exec ls -lad {} \;
You may need to run that as root, as some directories don't have read
permission for the common user. Note that some groups may exist that
have no members, and seem to own no files/directories. One example is
"nobody" - both a user and group that normally has no special
permission, and is used for administrative tasks that don't require
permissions, such as creating the 'whatis' files.
>Is there any documentation explaining what uucp, xok, pkcs11,
>icecream are? I know none.
Of those, only group 'uucp' is a standard. 'UUCP is a Unix to Unix transfer
mechanism. It was used primarily for remote sites to download and upload
email and news files to local machines before the Internet became common.
If you didn't already know that, you probably don't need it, but it's not
uncommon to find the serial ports owned by that group, as that's where
the modem lived.
>True, but as I just explained, for command-line progs it also not easy
>to find the group.
A lot depends on how your administrator (or lacking that, the people
who created your distribution) set things up. Most _users_ do not have
any permission to muck with the system. You can use the 'group' or 'id'
command to see what your users belong to - usually only 'users' but
this is distribution dependent.
Old guy
Similar Threads
Linear Mode
