On 2012-05-23, SpreadTooThin <bjobrie...
> I'm confused by these special execute permissions.
> It would seem that permissions can be 7777.
> The left most 7 is are special flags for the execute bit for owner, group and all.
The leftmost digit is for the setuid, setgid, and sticky bits (see
below). Only the last three digits are rwx for owner, group, and other.
(If you only specify three digits they never reference the set?id or
> a) I think that in order to cd into a directory you must have the execute bit set.
Yes. You also need the execute bit to get anything more than filenames
from the directory (e.g., file sizes), or to ''modify'' the directory
(e.g., adding a file to it). Note that you do *not* need read
permission on a directory in order to add a file to it!
> b) If an executable is found in a directory and executed from there it will run with the effective user / group id.
An executable will execute under the proper UID/GID regardless of what
directory it is located in.
It should be noted that none of these permissions are ''special'', in
that they have nothing at all to do with the leftmost 7. The only bits
you are talking about here are the normal execute bits.
The setuid bit and setgid bit on a file tell the kernel to run that
program using the file owner/group's effective UID/GID instead of the
userid which actually executes it. The setuid bit corresponds to a
leftmost 4 (if you give four numerals), and the setgid bit corresponds
to a leftmost 2. (It's generally better to use u+s and g+s.)
The same bits set on a directory tell the kernel to create new files
in that directory with the UID/GID of the directory instead of the userid
creating the file.
A leftmost 1 corresponds to the sticky bit. On a directory (typically
one that is world-writable) it tells the kernel not to permit users to
modify or delete other users' files. (''Modify'' in this context would
mean changing a filename; modifying a file's contents is still
controlled by the file's permissions.) It allows a world-writable
directory (like /tmp) without letting users clobber other users' files.
(It's generally better to use +t.)
The sticky bit is deprecated on files.
As I mention, it's generally better to use symbolic notation for the
set?id bits and the sticky bit. Octal notation won't always explicity
set those bits (unlike the rwx bits). If you know the current state of
a directory or file, and know your octal notation will do what you want,
then it's fine to use it and avoid the extra chmod. For example, on a
system that uses a /tmp that's transient (e.g., a ramdisk), you might
chmod 1777 /tmp
in a startup script.
> I'm confused by the 'linking' of permissions to cd into a director vs permissions that executables have that exist in a directory.
It's a way of simplifying permissions by somewhat overloading what they
mean for a directory. Since you wouldn't ''execute'' a directory that
bit can be used to mean something else.
(try just my userid to email me)
see X- headers for PGP signature information