subgroups

[Guest emetib]

is there a way to add a group to a group?

 

this is the senario-

folder /data

folder /data/mpeg

 

ok, i want to be able to have some people have access to /data/mpeg but not the /data. yet i also want the /data/ people to have access to the /data/mpeg.

 

i've tried like a work around for this but my results weren't what i would have liked to have seen. this is what i did-

useradd- public (/data/mpeg)

useradd-play (/data)

 

now with the two of these i made a /home/dir, don't know if i really needed to but. so what i then did was to put a couple of my users in the public group, that is to have access to it. then i put myself and public into the play group.

 

now, when i put something in the public, the other users could rename it, rm it, but couldn't read it. they couldn't see the play dir, which was good, and play could look at things in the pub. the read is what i wanted to happen. yet even with the files that were in the public, i didn't want the others to be able to change a file name that i had wrote. the user/group was me and not the others, so i don't know why they could have written those files to other ones. the ownership stayed the same on the files, yet the names should have been "permission denied" to have been changed.

 

would someone know how to do what i would like to do without having to put all of the people into seperate groups. i'm looking for a quick perm system without having to enter and remove people all the time from a group, where i could just change the perms of the group so that they wouldn't have access to it.

 

if this doesn't make sense, i will try and clarify it somemore if i can.

 

cheers.

[Gowator]

Erm, I think your attacking it from the wrong end so to speak.

 

The easy way is to create a group (play) and group public

 

However these then become secondary groups for the users, nothe other way round.

 

So user emitib can be a member of group emitib (default created by mdk)

but also a member of play and public. these must already exist as groups and it will be easy to assign a user to that group too. (though not strictly necassary)

so add a user called play and a user called public and let mandrake create the groups data and pulbic for you.

 

You add this under users/groups where you can add secondary groups.

 

Then chgrp play /data

chgrp public /data/mpeg

 

You might wanna use the -R (recursive if you already have files in there)

i.e. chgrp -R play /data

 

You can also assign them to the respective users but its not necassary if you set group permissions on the files.

If you do you can use UMASK to set the default for these users (in .bashrc) so they create with group permissions you want!!

 

Hope thats a bit clearer.....

Im just leaving work but from what I put and use man (manual) then umask or man chgrp you'll work it out, if not post back!!!

[Guest emetib]

i checked the man for umask and nothing. it comes up with a 'bash builtins' page. so i grepped man bash and nothing. i did some checking with the books that i have and found what i was looking for. not sure if it's exactly what i'm looking for, yet i'll end up playing with it some to see.

 

i've typed out what my book says, it's from linux + cert study guide so it's pretty reliable.

 

Setting Default Permissions

 

When a user creates a file, that file has a default ownership and permissions. The default owner is, understandably, the user who created the file. The default group is the user's primary goup, as described earlier. The default permissions, however, are configurable. These are defined by the user mask (umask), which is set by the umask command. This command takes as input an octal value that represents the bits to be removed from 777 permissions for directories, of from 666 permissions for files, when creating a new file or directory. For instance, to have Linux create files with 640 permissions, and 0750 directories, you would enter the following command:

 

$ umask 027

 

Note that the umask isn't a simple subtraction from the values of 777 or 666; it's a bit-wise removal. Any bit that's set in the umask is removed from the final permission for new files, but if the execute bit isn't set (as in ordinary files), its specification in the umask doesn't do any harm. For instance, consider the trailing 7 in the preceding umask command. This corresponds to a binary value of 111. An ordinary file might have rw- (110) permissions, but applying the umask's 7 (111) eliminates 1 values but doesn't touch 0 values, thus producing a 000 (binary) value_that is, --- permissions, expressed symbolically.

Ordinary user can enter the umask command to change the permissions on new files they create. The superuser can also modify the default setting for all users by modifying a system configuration file. Typically, /etc/profile contains one or more umask commands. Setting the umask in /etc/profile might or might not actually have an effect, because it can be overridden at other points, such as a user's own configuration files. Nonetheless, setting the umask in /etc/profile or other system files can be a useful procedure if you want to change the default system policy. Most Linux distributions use a default umask of 002 or 022.

To find what the current umask is, type umask alone, without any parameters. Typing umask -S produces the umask expressed symbolically, rather than in octal form. You may also specify a umask in this way when you want to change it, but in this case, you specify the bits that you do want set. For instance, umask u=rwx,g=rx,o=rx is equivalent to umask 022

 

edit: hey i was bored, i was updating my system. :D

Edited January 13, 2004 by emetib