Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
about setuid and setgid?
80 views
Skip to first unread message
SpreadTooThin
May 23, 2012, 3:55:50 PM5/23/12
to
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.
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.
SpreadTooThin
May 23, 2012, 4:49:16 PM5/23/12
to
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?
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?
Keith Keller
May 24, 2012, 2:32:32 AM5/24/12
to
On 2012-05-23, SpreadTooThin <bjobr...@gmail.com> wrote:
> 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
> 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.
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.)
> a) I think that in order to cd into a directory you must have the execute bit set.
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.
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.
> I'm confused by the 'linking' of permissions to cd into a director vs permissions that executables have that exist in a directory.
mean for a directory. Since you wouldn't ''execute'' a directory that
bit can be used to mean something else.
--keith
--
kkeller...@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
Barry Margolin
May 24, 2012, 5:14:22 AM5/24/12
to
In article <4cb3d55a-36a5-4f3d...@googlegroups.com>,
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.
> What does it mean to have a permission 2664?
>
> in other words... setgid is set but not setuid.
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.
> how can the owener not be part of the group?
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 ***
SpreadTooThin <bjobr...@gmail.com> wrote:
> 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?
Directory permissions have nothing to do with whether there are
> 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?
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.
> What does it mean to have a permission 2664?
>
> in other words... setgid is set but not setuid.
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.
> how can the owener not be part of the group?
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 ***
Doug Freyburger
May 24, 2012, 12:30:13 PM5/24/12
to
Keith Keller wrote:
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
"..".
> 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!
Those should be the write bit not the executible bit.
> 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.)
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.
> The sticky bit is deprecated on files.
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.
> SpreadTooThin <bjobr...@gmail.com> wrote:
>
>> 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),
For a regular file the execute bit means you have declared that the file
>
>> 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),
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
"..".
> 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!
> 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.)
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.
> The sticky bit is deprecated on files.
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.
hymie!
May 24, 2012, 12:39:53 PM5/24/12
to
In our last episode, the evil Dr. Lacto had captured our hero,
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
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
Keith Keller
May 24, 2012, 2:21:51 PM5/24/12
to
On 2012-05-24, Doug Freyburger <dfre...@yahoo.com> wrote:
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 Keller wrote:
>
>> 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!
>
> Those should be the write bit not the executible bit.
In my tests I needed both the write and executable bit on the directory
>
>> 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!
>
> Those should be the write bit not the executible bit.
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
Casper H.S. Dik
May 24, 2012, 3:13:57 PM5/24/12
to
Doug Freyburger <dfre...@yahoo.com> writes:
>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.
Sticky bit has nothing to do with group ownership; that's the set-gid
>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.
bit.
The set-gid bit on directories is also inherited by directories created.
There is also a mount option which enabled the BSD behaviour for
file creation.
The sticky bit has the same semantics on directories in both
systems on directories. (its use was first introduced in BSD).
For sticky-bit for plain files, it originally meant 'keep the executable
in the (faster) swap device' but in SunOS (from 3,x?) it was used to mark
files as "this is a swap file, don't bother about updating the file times
on writes and reads."
>> The sticky bit is deprecated on files.
>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.
It was reused for swap files.
Then the set-gid bit also has a meaning on files with the execute for
groups not set: it requires mandatory locking:
-r--r-lr-- 1 casper ir 0 May 24 21:10 2444
Barry Margolin
May 24, 2012, 7:00:33 PM5/24/12
to
In article <vqa299x...@goaway.wombat.san-francisco.ca.us>,
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.
Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> On 2012-05-24, Doug Freyburger <dfre...@yahoo.com> wrote:
> > Keith Keller wrote:
> >
> >> 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!
> >
> > Those should be the write bit not the executible bit.
>
> 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
That's correct. Here's how permissions on directories work:
> On 2012-05-24, Doug Freyburger <dfre...@yahoo.com> wrote:
> > Keith Keller wrote:
> >
> >> 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!
> >
> > Those should be the write bit not the executible bit.
>
> 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
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.
SpreadTooThin
May 25, 2012, 1:01:06 PM5/25/12
to
Many thanks all.
0 new messages