Question about groups
I've been studying about groups but am still a little confused.
When I run the command Code:
groups When I run Code:
groups joe What are the differences in these commands? I don't have my name in the groups for audio, but can play music,etc I don't have my name in cdrom,but can mount the cdrom. Is there some info on what the groups in Slackware are for? My default group for files and directories is users. Wouldn't this give access to other users installed on the computer access to my files? Thanks. |
see the sticky about hal
Quote:
|
Access to files, directories and device nodes isn't entirely dependent on groups, there are three levels of access. User, group and all. So if a file has permissions set as 666 (ie rw-rw-rw-) then everyone has access to the file, regardless of their user name or group access.
Typically home directories are set 711 (drwx--x--x) so everyone can cd into your /home/user directory but can't do anything inside, not even see a directory listing. They may be able to descend into a subdirectory (if they knew somehow that it existed) and view the contents there, depending on the permissions of that directory, and so on. In other words, there's more to life than just "user" and "group". |
Quote:
Have a look at groups(1), especially the NOTE in there about concurrent group sets. What you're seeing from running 'groups' with no arguments is the user's *real* group assignments (as defined in /etc/group) plus the supplementary groups added by shadow from /etc/login.defs (see the CONSOLE_GROUPS parameter in that file). Running 'groups joe' returns only the user's real groups defined in /etc/group. |
Quote:
these groups because of dbus, but I think I'm using groups now (I have sound,using cdrom...) without my name in /etc/group for them. Am I understanding this correctly? How do I turn on Hal. I don't think I chose that option when I installed Slackware 12? |
Forget about HAL and DBUS.
System objects such as files, directories, and devices, are owned by a user account and a user group. User groups are used by the operating system to identify which system objects, such as files and devices, a given user account is or is not allowed to access. You can set access permissions on any given system object to specify what kind of access is allowed for the user account that owns the object and for the user group that owns the object, and for all other user accounts that don't belong to either the user account or user group that owns the object. Therefore, user groups are part of the authentication part of Linux. When used correctly the user groups can help refine which users and groups of users are allowed access to particular system objects. Example one. Look at the properties of the system device /dev/cdrom. Code:
ls -l /dev/cdrom Code:
ls -l /dev/hdc Example two. Look at the permissions on a file in a normal user HOME directory. Code:
ls -l So we can see that although the file is owned by the user group called users the members of this group still have no permission to do anything with the file. You can create your own user groups, make whatever user accounts that you want to be members of this group, make any system objects owned by this group, and then set the access permissions for this user group to access the system object. Most of the time the system object will be a file or directory or groups of files and directories. Example three. Make a work area for people in the Accounting Department. First make a user group for the members of the Accounting Department. Log on as root to perform all of the commands in this example. Code:
groupadd accntg Code:
usermod -G accntg mary Code:
mkdir /home/accntg Code:
chown root:accntg /home/accntg Now let's set the permission on the /home/accntg directory to be sure that members of the accntg group can read, write, and execute the /home/accntg directory. This is necessary for the users to be able to write and delete files, and to list the files in the directory. Let's also add the sgid bit on the directory. That will mean that all of the files created in the /home/accntg directory will be owned by the accntg user group. Code:
chmod 2770 /home/accntg Code:
ls -ld /home/accntg Code:
touch /home/accntg/delete-me.txt I hope this helps explain how the user groups can be used. |
Stress_junkie you are AWSOME. I have been having issues with permissions for a "common" directory form me and another user to use. I kept having to change the permissions manually so that we can both have read/write access. I read the man for chmod and don't understand where you got the "sgid bit" from. I never had an idea. Where do you guys learn this stuff.
Moderator, please recognize Stress_junkie. erik |
Nice explantion stress_junkie,
I know you skipped over this for simplicity but it may be worth mentioning that the Code:
usermod -G group user Probably a good Idea to check what groups the user should be in and use something like. Code:
usermod -G group1,group2,newgroup user |
You could use the gpasswd command instead, then you don't need to know which groups a user is in already. For example the following will add mary and jim to the accntg group without altering any other groups:
Code:
#gpasswd -M mary,jim accntg Code:
#gpasswd -a accntg mary Code:
#for i in mary jim; do gpasswd -a $i accntg; done |
Thanks for everyone's help. I have a better understanding about this now.
|
I have misread the explanation. Only discovered it when I was fooling with my directories.
My goal is to find a way where group members can all have read/write/execute permissions in a particular directory. stress_junkie pointed me in the right direction. However, I failed to notice that when a user creates a file, only that user has read/write permission. I'm looking to share all permissions for specified users. Is there a way to do that automatically when files/directories are created? Thank you All. |
You can change the "umask" line in /etc/profile so that all new files/directories have the inverse permissions (in other words the bits following umask are cleared), so for instance "umask 0022" means that the write bit for all and group are cleared, so a newly created file would have the permissions set as -rw-r--r-- (files are not typically created executable), and newly created directories would be drwxdr-xdr-x. "umask 0002" would be -rw-rw-r-- and drwxrwxr-x and so on.
Instead of "umask 0002" you could write "umask a=rx,ug+w" which means all users have read and execute permissions (execute where applicable), and user and group level would have write permission. I'm not sure if it's possible to set it up so that if you're in one directory one umask is used, and if you're somewhere else another umask is used. Generally 0002 is a reasonable compromise between security and accessibility, but you may want to have each user use their own username as their default group so that people can't snoop in other's home directories. |
All times are GMT -5. The time now is 10:59 AM. |