Assigning group rights (was: Re: Root isn't God

[Bruce W. Bigby]

On Sat, 2003-12-20 at 20:46, A.J. Bonnema wrote:
> Bruce W. Bigby wrote:
> 
> > Here's an example of my fstab entry:
> > 
> > /dev/hda1       /c          vfat   
> > defaults,uid=bigby,gid=bigby,umask=007   1 2
> > 
> > The umask makes the files and directories rwx for user and group, and
> > NOT readable, writable, or executable by other.  The bigby is my family
> > group. Anyone in my family can read, write, or search/execute the
> > files.  Noone else can do a thing.
> 
> Ok, I guess thats a good idea. I still wonder though how the group-thing 
> works. If someone is in group bigby, say user1. Then she logs on to 
> userid user1 and gets the permissions for user1. Are all group 
> permissions assigned automatically, or do you have to change group in 
> some way?
> 
> Guus (have been using Linux for some time now, but still not clear on 
> some issues. That's for being a non-sysadmin at work).

By default, every user belongs to at least one group. Also, by default
convention, when RedHat creates a new user -- say abonnema -- it also
creates a corresponding group of the same name of which the user
abonnema is a member.  In other words, you have your own group of which
you are a member. Whenever you create a new file, by default, the file's
ownership/user will be abonnema and its group will be abonnema.

If you like, you can add another user to your group. For example, if you
edited /etc/group and added me, bbigby, to the group, adonnema, then you
might see a line like the following:

adonnema:x:500:bbigby

The 500 represents the unique identifier for the user, adonnema, which
appears in the /etc/passwd file. bbigby is a user name that also appears
in the /etc/passwd file.  Now, I have access to any file whose group
owership is adonnema.  However, that's not it.  How I may access the
files depends upon the access rights of each file -- whether I have
read, write, or execute permission, and in the case of directories,
whether I have search permission.  You can set these permissions
individually.

For example, if you use the command, ls, to list the attributes of the
file, /etc/motd, you might see the following:

-rw-r--r--    1 root     root            0 Jan 12  2000 /etc/motd

The first field, above, is a '-'.  It represents whether the file is a
directory or a file.  If the file were a directory, you would see the
letter, d. Since this file is not a directory, you see a '-', instead.

If you list the root directory with the ls command and specify the '-l'
option, you might see the following:

drwxr-xr-x   29 root     root         4096 Aug  3 17:55 var

As you can see, the file, var, under / is a directory.

The next 3 characters represent the read, write, and execute/search
permission of a file/directory. The letter, 'r', means read permission. 
The letter, 'w', means write/modify permission.  The letter, 'x', means
the file is executable, or in the case of directories, the directory is
searchable.  Note: It is possible for a directory file to be searchable
but NOT readable.

In the case of the file, /etc/motd, reading from left to write, this is
what we find:

The first field in the rights specification,

-rw-r--r--

is a dash so the file is a regular file. The next 3 fields indicate the
access rights for the owner of the file.  The file is readable,
writable, and not executable for the owner.  The following 3 fields
indicate the access rights for each user whom is a member of the group
to which the file belongs.

In the case of the file, /etc/motd, and the directory /var, the owner is
the user root and the group to which the file belongs is also root.
Note: The user and group need not have the same name.  For the file,
/etc/motd, anyone in the group may read the file but no one in the group
may write/modify the file or execute the file.  The last 3 fields in the
specification indicate the access rights for everyone else.  Every other
user can read the file but they may neither write/modify the file nor
execute the file.

Basically, groups are a way for you to allow more than one person to
access a file.  However, groups allow you to restrict access to a very
specific set of users.   Without groups, you would really only have 2
classes of user -- the owner and everyone else.  In this case, there
would only be 1 group -- everyone else.

Note: In my case, I set the general ownership of my vfat file system
files to the user, bigby, which is my family user id.  I set the group
to the bigby group.  Everyone whom is a member of the bigby group can
read, write, or execute/search the files/directories on the vfat disk.

Imagine that you have a LimeWire (peer-to-peer file sharing software)
repository and you store a bunch of files under a particular directory
under Windows. Let's say, you reboot into Linux and you run LimeWire
under Linux but you wish to use the same directory for LimeWire under
Windows.  Well, you give everyone in your family the ability to read and
write to the vfat disk so that when they run LimeWire, they are storing
to the same directory.  To accomplish this, you add every user in your
family to the bonnema group and you mount your vfat disk as I have done,
but using the the name, bonnema, since that is your family name.

I hope that this is clear.
-- 
Bruce W. Bigby
http://home.rochester.rr.com/bigbyofrocny
Don't be fooled by sale pitches.  The only money that you save is
money that you keep.  Anything less is a deception.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20031220/6f28f6bb/attachment-0002.bin