Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

On campus, everyone's primary group is user and each person is additionally associated to groups depending on the courses he or she is taking, lab he or she works at, etc.

My coworker and I are members of group foo, so we use newgrp foo and umask 7 to ensure our files are accessible to the two of us without granting everyone permission. Neither of us minded this.

However, we now need our PATH environment variable to first point to our lab's bin folder before the rest in the PATH. We thought a simple script would work, but it doesn't as the PATH's contents don't persist after executing newgrp:

#!/bin/tcsh
setenv PATH "/path/to/lab/bin:$PATH"
newgrp foo

The default shell is tcsh. Does anyone have any suggestions?

Thanks!

share|improve this question
    
What operating system(s) are you using? What network filesystems (NFS, AFS, …), if any? Are access control lists (ACLs) available? Are you willing to change your work habits a little (e.g. use chgrp more and newgrp less) if it turns out to be possible? –  Gilles Apr 8 '11 at 20:29
    
CentOS 5.4. Our project is stored locally on the server. We are using Python with custom modules and hence why we want the Python in our bin ran before the system's. And yes, we are willing to change work habits. –  alfyboza Apr 8 '11 at 20:38

1 Answer 1

up vote 3 down vote accepted

Unless you need to type a password when you run newgrp (a very rarely used feature), you don't need to use newgrp to make files owned by the appropriate group. You can use chmod instead. For example, instead of the following workflow:

newgrp lab1
mkdir project1
$EDITOR project1/file1

you can do this:

mkdir project1
chgrp lab1 project1
$EDITOR project1/file1
chgrp lab1 project1/file1

On most current unices, either project1/file1 will already belong to lab1 like the directory it contains (*BSD), or you can force this behavior (Linux, Solaris, …):

mkdir project1
chgrp lab1 project1
chmod g+s project1
$EDITOR project1/file1

All of this requires that your umask be set to 002 or 007.


It's easier to manage permissions if access control lists (ACL) are supported. ACL support must be present in the disk filesystem driver and enabled in the mount options, and again for the network filesystem if applicable. ACLs support is not yet generalized, so you might not have it.

To see if you can use ACLs, on a Linux client, try running

touch foo
setfacl -m user:myfriend:rwx foo
ls -l foo

If the permissions of foo show up as -rw-rw-r--+ or similar (with a + at the end), ACLs are enabled. If the setfacl utility isn't available, then your campus network probably doesn't have ACLs all around.

If you do have ACLs, then you don't need to have a permissive umask, you can stick with 022 or 077. With ACLs, to set up a group-writable directory (where newly created files will be writable by the group as well), do

mkdir project1
setfacl -m group:lab1:rwx project1; setfacl -d -m group:lab1:rwx project1

In addition to not requiring a permissive umask, ACLs let you share files between an arbitrary set of users and groups.

share|improve this answer
    
Thanks! ACLs are not set up, but chmod g+s did the trick! –  alfyboza Apr 8 '11 at 22:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.