Re: Changing groups
"Dan Jones" <ddjones@riddlemaster.org> writes:
> On Thu, 2003-08-14 at 07:44, Colin Watson wrote:
> > On Thu, Aug 14, 2003 at 06:54:34AM -0400, Dan Jones wrote:
> > > Is there no way to change your group under a GUI? Executing newgrp
> > > under a terminal only affects that session, not the parent GUI
process.
> >
> > You have to log out and back in again, I'm afraid.
> >
> > > If I set up groups and give them access to various files, can I only
> > > access those files from a command line? Doesn't that defeat much of
the
> > > usefulness of having groups in the first place?
> >
> > Not really; on the average Unix system, groups aren't usually so
> > rapidly-changing that the need to restart processes in order to acquire
> > them is a major problem.
>
> Average Unix systems don't exercise selective control of files by
> users? If I want to make certain files only viewable or writable by
> certain users, how do I do that other than by groups?
Desirable Unix filesystems do allow selective control of files using user
and group id's. Ext(2/3) is an example of one such file system. FAT
is not. The point was that group definitions don't usually appear and
disappear on say an hourly basis and users are normally logging out
and in more often than groups are created or group assignments are
made.
>
> For example, say I supervise several teams working on a project. Each
> person should have access to only the project directories of their
> teams. However, some people are on more than one team. And as
> supervisor, I'm a member of them all. I have exactly this situation at
> work and cant' believe that my requirements are that unusual. At work,
> however, we're Microserfs and setting the requisite access privileges is
> trivial under NTFS. I'm trying to set up a similar situation on my home
> LAN (a mixture of MS and Mandrake desktops with Debian servers) and
> finding it difficult to do.
>
First I'd like to make sure I understand what you are trying to accomplish,
which may be different than what you are trying to do. From your example
it sounds like you would like to have some directories where only certian
people can read from or write to the contents of the directories. Maybe
something like this:
paleader is the user who is the leader of project a.
pbleader is the user who is the leader of project b
pleadera, bob, joe, sue are members of group projecta
pleaderb, sue, frank, ed are members of group projectb
Everyone is a member of group user.
drwxrws--- paleader projecta 1024 Aug 14 /home/project-a
drwxrws--- pbleader projectb 1024 Aug 14 /home/project-b
drwxrws--- root users 1024 Aug 14 /home/share
With this set up bob cannot even see the files in /home/project-a,
and frank cannot even see the files in /home/project-b. Sue can
see the contents of either directory, write new files into either
directory and if the group sticky bit was honored when files
were created in that directory and if files were created with group
read/write permissions she could modify existing files in that
directory. Everyone can write files into /home/share and again
depending on the file's permissions they can read and write the
files. Everyone can delete files in /home/share.
Is this what you are looking for? It seems your example is broadening
the scope from just one server to multiple systems including MS Windows.
I do this all the time, using Samba. Samba allows you to restrict user
and group access to directories in it's configuration and set the default
file mode so that files would be created with the group read/write
permissions.
You can even add 'superusers' into samba who have full access in any
share. The Samba config file paired with proper file and directory
permissions
should make about anything possible.
You started out asking about switching groups for GUI programs,
but I don't think that's what you need. Lets say Sue's default group
is users, but she belongs to projecta and projectb. If she writes into
/home/project-a/mynewfile.txt with the standard file permission mask
using gvim it will turn out like this:
-rw-r--r-- sue projecta 23 Aug 14 /home/project-a/mynewfile.txt
She didn't need to use the chgrp or newgroup commands, and she
didn't need to log in as sue.projecta. Because the group existed before
she logged in, and she was a member of that group before she logged
in, she was able to create a file with that group id. It happened
automagically because the group sticky bit was set. On the otherhand,
and I believe this is what Colin is pointing out, if you created the
projecta group or added her to it's membership before she logged in
then she would need to log out and back in before she could even
list (execute) the contents of that directory.
The only issue left with her file is the default umask, or file creation
mode mask. If you want bob and joe to modify sue's file instead of
just deleting and re-creating it, the umask needs to be set such that
the file has group write permissions. Again if this is a network file
server, Samba has settings that do a pretty good job of that.
Best of luck with the home network,
Jacob
jacob@cachevalley.com
Reply to: