Default group


when i create a user, there is a default group attached to it.
userA belongs to "default_group"
i want to move userA to a completely different group.
e.g. move userA to a group called “custom_group” and userA will no longer be in "default_group"
how can i do that?


I quote the Groups page: “Default groups cannot be edited.” So userA is permanently a member of your default group.

What’s wrong with leaving userA in the default group? If you want to block some access, then create groupB and put your privileged users into that group and userA into groupA.



The problem is when you need userA to have access to ONLY userA files, and userB to have access to ONLY userB files and they’re not unix saavy enough to newgrp every time they login (or change their file/folder group ownership all the time).


How about using chmod g+s on directories?


That still has problems, the biggest one being that you have to remember to reset the sticky bit if you change the group of a folder.

What do you think about this solution using a cron job?


Yep, you do need to remember to reset the setgid bit (not the sticky bit, which has a different purpose) after changing groups. How about using setgid, but reinforcing it with that script? You could extend the script to reapply the setgid bit.

What are the other problems with setgid that you referred to?


I’ve just come across a completely different problem with this approach. My Perl CGI scripts won’t work (they give a 500 error) if they’re in a secondary group, but they work fine if the scripts are in the user’s primary group. I’ve got no idea why. Anybody seen this?


Who owns the script? Apache runs as the user/group who owns the site. If that user doesn’t have permissions to that script, then it’s not going to run.



The script is owned by the user who owns the domain. Also, if it was a permissions problem then I’d hope to get something informative in the logs, but all I was getting was something like:

[Mon Aug 7 00:47:45 2006] [error] [client nnn.nnn.nnn.nnn] Premature end of script headers: /home/xxxx/yyyy.zzz/ Very odd.


Just had a reply from DreamHost Support about this.

I asked:

The reply was:


Apologies for replying to myself again, but, for future info, this is just standard behaviour of suEXEC. Looking at, it seems that my script was failing at point 18 of the process. Specifically:

Is the target user/group the same as the program’s user/group?