[Solved] Best way to change umask?

[[n00b@localhost]]

I am about to start creating multiple users on my gentoo system so that the rest of my family can get access to the files they used to have on my old XP machine. All the files and folders underneath my home directory are readable by anyone else in the same group (users - ie the rest of my family) and I don't want them snooping through my emails/mp3s/porn. I know that I will have to change the umask so that any files and folders created by me (or the rest of my family) will have the correct permissions but don't know the best way to do it. The options I have are:

• Change the umask in /etc/profile
  This changes the umask for everybody on the system but from this thread and others on google this looks like it can be dangerous on some systems. Is this likely to be the case on gentoo (I am thinking of changing it from 022 to 077)?
• Change /etc/fstab to mount /home as umask=077
  Since /home is on it's own partition this would set the umask for every file and folder under /home. I am worried about login scripts sourcing /etc/profile and changing the umask back to 022. Is this likely to happen and will the umask setting in /etc/profile override the one for the partition in /etc/fstab?
• Use ACLs
  I could use Access Control Lists on /home to limit access to my files but to me this seems like overkill and might suffer the same problems as above (what happens when /etc/profile is sourced?).

I would like to go with the first solution (changing /etc/profile) but don't know if it is likely to break my system or not. Does anyone here use any of the above ways to change the umask? What one is the best to use?

[IQgryn]

I have changed the umask via /etc/profile to 077. The only real problem I have is with the default permissions on the kernel config file (I have to re-enable read access to everyone on it after any changes, or running any portage utility as user fails).

[gsoe]

I have been trying to find a way of setting the user umask and leaving the rest of the system unaffected. So far I have come up with the following:

1. Set the umask for creation of the new users $HOME directory (with useradd -m) in /etc/login.defs, say

Code: Select all

UMASK 077

2. For files created by the user in bash, add a

Code: Select all

umask 077

statement in /etc/skel/.bashrc
3. Finally, for files created by the user in GUI, I've only found out how to handle KDE: kdm runs /usr/kde/3.5/share/config/kdm/Xsession at userlogin, which in turn sources $HOME/.xprofile if it exists. Consequently

Code: Select all

echo "umask 077" > /etc/skel/.xprofile

does the trick.

Now, there's probably some weak points in this method, e.g. like what happens if the user starts a different shell than bash? That could be taken care of by setting the environment for that shell as well, but taking care of any possible hole with the above method could be a little tedious. One could take the point of view, that if you as a user don't want anybody to look into your files, then you should be a little careful when working in non-standard environments.

Anyway, I found another method: In /etc/profile we could distinguish between ordinary users (1000 <= uid <=60000 in Gentoo) and everything else like this

Code: Select all

if [ $(id -u) -gt 999 -a $(id -u) -lt 60001 ]; then
  umask 077  # normal user
else
  umask 022  # root & any system account
fi

I took the idea from an (Red Hat I think) profile, I found here, but I haven't tried it out yet, one might have to combine with 1. from above.

Please feel free to comment on these methods.

[Genone]

Forget about the fstab option, the umask option is only for filesystems without permissions (like ntfs or vfat).

[timeBandit]

In my experience there's a happy medium. Set the default umask to 027 by whatever means you prefer, then either use Red Hat's model of eponymous groups for every user, or, don't make other users members of your user's default group. Use additional group memberships and ACLs to open/close holes as needed.

[mudrii]

create new group for your relatives and separate from you own group and this should make a diff for non group acess with some permition change may involve.

[gsoe]

timebandit: Of course you are right about that; the groups are there to govern who have access and how they have it, not to deny any access. If you don't want them to peek, don't let them be in your group. I was merely wondering how to technically set other options for the system.

[[n00b@localhost]]

Hey guys. Thanks for all your replies!

I have gone with changing the umask in /etc/profile, /etc/login.defs and /etc/skel/.bashrc (I don't have an /etc/skel/.xprofile). No problems so far!

I think I can live with having to manually change the permissions on /usr/src/linux/.config however I don't understand why running any portage utility as a user would fail. Why would they need to read the kernel config? As far as I'm aware that is only used when compiling and installing external kernel module ebuilds which requires being root anyway.

Not to knock Red Hat or anything but I don't really see the point in their one user per group system. Doesn't that defeat the purpose of groups altogether seeing as the group permissions on any file would have no effect (since a group is a user and vice versa)? I like their /etc/profile idea to set the umask depending on the user though.

Does anyone know how to format a "find" command to change the permissions of all file and directories under $HOME? Should I do this for my whole system or is that just asking for trouble?

[gsoe]

This should do it

Code: Select all

cd
chmod -R 700 *

[[n00b@localhost]]

Actually I should maybe have been more clear:
I am looking for the syntax for a find command that will change the permissions of all files to 600 and directories to 700 under my home directory.

[timeBandit]

I am looking for the syntax for a find command that will change the permissions of all files to 600 and directories to 700 under my home directory.

Code: Select all

cd $HOME
find . -type d -print0 | xargs -0 chmod 700
find . -type f -print0 | xargs -0 chmod 600

man find is your friend, this wasn't a tough one. If you have any executable scripts or programs anywhere beneath in your home directory, that will temporarily break them....

Not to knock Red Hat or anything but I don't really see the point in their one user per group system. Doesn't that defeat the purpose of groups altogether seeing as the group permissions on any file would have no effect (since a group is a user and vice versa)?

No. The idea is to give control over group membership to administrators (at the system and group level) and leave responsibility for group file access in the hands of the group members. Administrators create additional groups as needed to suit the organization (e.g., research, devel, dba, sales, etc.), add users to those groups and possibly change a user's default group to an organizational one. Since a new user doesn't belong to any groups but his own, this also places very tight constraints on new/untrusted users.

Users are expected to change the group ownership of files and directories they wish to share with a particular group, and manage permissions as well. In conjunction with a umask that denies world access, this approach ensures all new files are private by default, even in shared directories.

It's a model that works best in larger organizations, where segregation by role actually matters and there really is a concept of a new and untrusted user. It also is more suited to a somewhat savvy user base that understands the UNIX permission model tolerably well.

And then in practice, people just run chmod 777 on every file they want to share.

[[n00b@localhost]]

Thanks for that. I find the syntax of find very confusing!

I guess the Red Hat (and others) model of users/groups does make more sense in a corporate environment but since I'm using Gentoo on my home PC (where theoretically I should trust every user on my PC) I think the other model makes more sense.