groups vs users

On Sat, 10 Feb 2007 15:50:36 +0000 (GMT), Dave Stratford
<daves.RemoveThis@orpheusmail.co.uk> wrote:
>
>
> Hi,
>
> Can someone please explain to me how groups work as my understanding
> appears to be faulty, or at best only partial.
>
> On my own box at home, I have a user, dave, which I do most of my basic
> development work in. However part of this requires access to /var/www/html.
>
> I created a group, dev, and made the user dave part of that group. I then
> changed the group of /var/www/html to dev, but left the owner as root.
> Then I did a chmod g+w html (I'm in /var/www at this point) and that
> worked. I then did exactly the same thing to /var/www/cgi-bin.
>
Did you then log out as dave and log in again? When you change a user's
group memberships the change affects subsequent login sessions.


--
What we do not understand we do not possess.
-- Goethe

Bill Marcum wrote:
> On Sat, 10 Feb 2007 15:50:36 +0000 (GMT), Dave Stratford
> <daves.DeleteThis@orpheusmail.co.uk> wrote:
>>
>> Hi,
>>
>> Can someone please explain to me how groups work as my understanding
>> appears to be faulty, or at best only partial.
>>
>> On my own box at home, I have a user, dave, which I do most of my basic
>> development work in. However part of this requires access to /var/www/html.
>>
>> I created a group, dev, and made the user dave part of that group. I then
>> changed the group of /var/www/html to dev, but left the owner as root.
>> Then I did a chmod g+w html (I'm in /var/www at this point) and that
>> worked. I then did exactly the same thing to /var/www/cgi-bin.
>>
> Did you then log out as dave and log in again? When you change a user's
> group memberships the change affects subsequent login sessions.
>
>
Also the group needs access right to the DIRECTORY to create files therein.

This message is not archived

It's been a few years, but also try overiding the file
permissions on the directory, so files are created
owned by dave no matter the account.

On Tue, 13 Feb 2007, in the Usenet newsgroup comp.os.linux.setup, in article
<pan.2007.02.13.14.50.41.257961 RemoveThis @netscape.net>, robert wrote:

>It's been a few years, but also try overiding the file
>permissions on the directory, so files are created
>owned by dave no matter the account.

Wish you had quoted some context so we know what you are talking about...

OK the O/P wrote:

>>I created a group, dev, and made the user dave part of that group. I then
>>changed the group of /var/www/html to dev, but left the owner as root.

>>The files and directories that I copied in remotesly, all have an owner
>>and group of dave, which I sort of expected.

so I'm not sure how your answer fits in. I believe what you are thinking
about is changing the permissions to "2775" which would be displayed as

drwxrwsr-x 1 root dev 2048 Jan 1 1970 /var/www/html

(note the 's' for group execute permission) and this would cause files
created in this directory to be owned by the user (dave) but the group
owner would be the owner of the directory (dev) and NOT the primary group
of the owner. This isn't as well documented as it should be, but is
found in the 'Introduction to Linux' guide (Intro-linux) from the
Linux Documentation Project.

There is no way to set directory permissions such that the _owner_ of the
files created can be other than the person creating the file (that is,
setting the _directory_ SUID or 4775 has no effect on file ownership).

Old guy

This message is not archived

On Thu, 15 Feb 2007, in the Usenet newsgroup comp.os.linux.setup, in article
<4eb5518e23daves.TakeThisOut@orpheusmail.co.uk>, Dave Stratford wrote:

>Moe Trin <ibuprofin.TakeThisOut@painkiller.example.tld> wrote:

>> I believe what you are thinking about is changing the permissions to
>> "2775" which would be displayed as
>
>> drwxrwsr-x 1 root dev 2048 Jan 1 1970 /var/www/html
>
>> (note the 's' for group execute permission) and this would cause files
>> created in this directory to be owned by the user (dave) but the group
>> owner would be the owner of the directory (dev) and NOT the primary
>> group of the owner.

>It took me a while to work out what the 2775 (in particular the 2) did.

OK - I should have done a bit more explaining. As stated, neither the
man or info pages ('man chmod' verses 'info chmod') give the greatest
explanation of what the flags do. Using the octal value rather than
the alphabetical values is just an experience thing. I'm used to working
with the numbers, and not as comfortable with the letters. Each method
has it's uses, strong and weak points.

>I noticed the s in the display, and then played around, moving, copying
>and creating files to realise what was happening. It's exactly what I
>wanted and needed.

You still need to be a member of the group (to have write access), but
you don't need to run the 'newgrp' command to make a specific group your
'primary' group ID. Yes - very handy.

The Xnnn numeric sequence has eight possible values (like the other
digits), but there are some differences in the effect on a directory
verses on a file. Also, how an 'ls -l' command _displays_ the resulting
mess is less obvious.

For directories, only 1xxx and 2xxx have meaning (4xxx does nothing). If
you look at /tmp or /var/tmp, you'll see that these directories are
readable/writable by everyone, and that _can_ be bad news when you have
"playful" users (like students in a class sharing a directory). So we
change permissions on that directory from '777' (the leading zero is
implied but not shown) which would be

drwxrwxrwx 1 root root 2048 Jan 1 1970 /tmp

to '1777' which changes the "others" permission to 't' (o=t is the
letter version of the '1xxx' bit) and this gives

drwxrwxrwt 1 root root 2048 Jan 1 1970 /tmp

The effect of this change is that only the Owner of a file (and root)
can delete it. Without this, anyone who can _write_ to the directory can
also delete files in this directory, leading to much student hilarity.
You _may_ find someone setting a group directory to '1770' and setting
the group ownership to something like 'students' to prevent "outsiders"
from accessing the directory. This would show as

drwxrwx--T 1 root students 2048 Jan 1 1970 /tmp/students

Note the 'T' rather than a 't' - meaning that the sticky bit is set (1xxx)
but the 'others execute' permission is NOT set.

The '2xxx' permission on a directory (g=s) has been described upthread.
The not-very-useful permissions of 2740 (SGID, but without the execute
bit needed to _list_ the directory contents) would show up as a 'S'
rather than 's' in the ls output. (drwxr-S---).

Note that these actions are different for _files_ as compared to
directories. For files, the 2xxx and 4xxx permission causes
executable _binary_ files (does not apply to scripts) to be run with
the GID or UID of the file owner, rather than the person who actually
invoked the binary. The 1xxx bit has no effect any more, but used to
mean that if the file were swapped OUT of memory, it didn't have to
be saved to swap space, but would be reloaded from permanent disk
space when the file were swapped back IN. This is a relic of the past
when both RAM and disk space were expensive and could profitably be
used for other purposes.

Old guy