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.

I'm not sure I understand its purpose.

a) I think that in order to cd into a directory you must have the execute bit set.
b) If an executable is found in a directory and executed from there it will run with the effective user / group id.

I'm confused by the 'linking' of permissions to cd into a director vs permissions that executables have that exist in a directory.

What if you want people to be able to CD to a directory but you don't want or don't have executables any where in the tree....  do you just set the gid and uid bits?

What does it mean to have a permission 2664?

in other words... setgid is set but not setuid.

how can the owener not be part of the group?

On 2012-05-23, SpreadTooThin <bjobrie...@gmail.com> wrote:

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
sticky bits.)

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!

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
see

chmod 1777 /tmp

in a startup script.

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.

--keith

--
kkeller-use...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

In article <4cb3d55a-36a5-4f3d-a569-c5077bc8cee8@googlegroups.com>,

Directory permissions have nothing to do with whether there are
executables in them.  The execute permission on a directory doesn't have
anything to do with executing things, it's just used by convention to
control whether you can access files in that directory.

Since you don't have any execute permissions set, the setuid and setgid
bits aren't relevant.  So I'm going to assume you really meant to ask
about 2775.

This means that while running the program their GID will become that of
the program.  This will allow them to access files in that group which
they might not otherwise be able to access.

Why can't he?  Maybe the program was installed by superuser, who can set
owners and groups to anything he wants.  So he can set the owner to
someone who isn't a member of the group.

And what difference does it make if the owner is or isn't a member of
the group?  If someone ELSE runs the program, they still need to switch
into the group that has access to the files it uses.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

For a regular file the execute bit means you have declared that the file
can be run.  For a directory file the execute bit means you have
declared that the directory can be searched/scanned.  Being able to cd
in to the director yis a side effect of being able to scan for "." and
"..".

Those should be the write bit not the executible bit.

Old use of the sticky bit - Use System V semantics when creating a file
in the directory when the sticky bit is clear.  Files get the group
ownership of the process.  Use BSD semantics when creating a file in the
directory when the sticket bit is set.  Files get the group ownership of
the directory.  I very much prefer the newer setuid/setgid usuage for
directories but I thought Solaris still used the old method as of
Solaris 10.

When the file is executed have the loader write the translated load
image into swap space then jump to it.  Assumed that the loader
sequence was more expensive than that swap-in process which stopped
being true when shared libraries were introduced.

In our last episode, the evil Dr. Lacto had captured our hero,
  SpreadTooThin <bjobrie...@gmail.com>, who said:

The group of a file does not have to be one of the groups that the owner
belongs to.

Also, each set of permissions **excludes** the smaller groups.
So group permissions specifically mean "everybody in the group except
the owner", and "other" permissions specifically mean "everybody except
the owner and people in the group"

--hymie!    http://lactose.homelinux.net/~hymie    hy...@lactose.homelinux.net
--------------------------------------------------------------------------- ----

On 2012-05-24, Doug Freyburger <dfrey...@yahoo.com> wrote:

In my tests I needed both the write and executable bit on the directory
to touch a file:

$ mkdir test
$ chmod -x test
$ ls -ld test
drw-r--r-- 2 kkeller arkin 6 May 24 11:19 test
$ touch test/test
touch: cannot touch `test/test': Permission denied

--keith

--
kkeller-use...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

In article <vqa299xo26....@goaway.wombat.san-francisco.ca.us>,
 Keith Keller <kkeller-use...@wombat.san-francisco.ca.us> wrote:

That's correct.  Here's how permissions on directories work:

read: allows you to list the names in the directory.
write: allows you to modify names of things in the directory, i.e.
creating, removing, and renaming things.
execute: allows you to access things in the directory.

So as a minimum you need execute permission to do anything with the
contents of a directory. Read and write then give you additional
capabilities.

With execute but not read, you can access files if you know their names,
but you can't list the directory to find names you don't know.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Many thanks all.