The wording of man pam_umask seems pretty much the same as what used to be in login.defs before. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=login.defs.diff;att=1;bug=282822
I have also made the experience that some graphical user managment tools do not keep gids eqal to uids and that tools create subdirecories in the homes, mimiking other OSes behaviour, but /etc/skel is not used for this. The writers of desktop environment tools do not seem to allways follow unix philosophy. I noticed debian policy states: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." (http://www.debian.org/doc/debian-policy/ch- opersys.html#s9.2) --- Just as you write, configuring pam_umask to provide unified means to set the umask for all sessions does not yet automatically (re)enhence default permission handling. If the default umask enables easy usability of permission handling, or does pretty much not support it, it should maybe be less the the result of the shiped pam implementation and adhere to the all time shiped configuration. (USERGROUPS_ENAB yes) Which grants 002 only if it's pretty safe and a feature, many times reported to not work properly and hacked around. (Even though many ubuntu users may have never noticed, and may just think file permissions just allways are like an inflexible pita style thing.) As the user groups created by default have all the time been private ones, it should be pretty save to let the 022->002 mapping do its work for them. The corner case being of course those that are really using sticky sgid directories without actually figuring out to change the umask. Meaning those that manually change filepermissions every time to be able to collaborate with other users, even when they decide to expicitly save stuff into special group places instead of saving into more private (sub)dirs. If we find a good name for that behaviour, we could actually provide sticky non-sgid subdirectory examples to publish something readonly within a group. (Does /home/share/<group>/writings /home/share/<group>/readings compare to /home/<user>/private?) >From the point of the implemented private user groups, if you want that other members of a group can work on a file together with you, they need to be in a group with them and you have to save the file into a special setgid directory, if not keep the file at home, in a private place if you don't want others to be able to read it. For shared write access you save it under the (sgid) group directory. This seems to be the feature and having to fiddle with file permissions is bugging users. Private user groups with umask 002 and a nice set of default directories are quite a feature, I would say. They should be save as long as filessystems are not transfered verbatim to systems with other group setups, but then, when transfering filesystems to other machines one allways has to watch for differences in IDs, anyway. All copy processes should honor the umask on the target systems, if not explicitly overridden to preserve permissions and numerical ids. Maybe I just don't understand that much of the private user group approach that I see it as quite important to provide it for ubuntu users to easily share and lock up files by choosing the location and not having to fiddle with file permissions. From experience though, I've gotton complaints about "those ever complicated and never satisfying file permissions", and wishes to just do away with them, but with private user groups, umask 002, the almost self explanatory fact that access depends on the location where you put stuff (directiory) _and_ file permissions, and by providing some (sample) directories, users fiddling and getting fed up with filepermissions gets allmost a non issue. "Ok, just save that privately in our <...> group dir (/home/share/<...>/private), I'll take care of it"! (Hmm, you made me think of <grouip>/writings now and I seem to like that idea.) What would be another way to provide good collaboration experience? If ubuntu really allways intended to ship current user and file permission setup with that umask, and the 022 setting in effect together with USERGROUPS_ENAB yes has not been just a result one wasn't particularily aware of, stemming from the once missing pam functionallity, waiting for a fix, and admins adjusting umask settings for multi user systems, what is the reason to ship private user groups? Comparing to umask 022 systems with all users belonging to the users group, users do not only have to manualy give write permission, to say to the users group in the simpliest case, but also need to change the group ownership on any file to collaboorate on it with others. (Note that its asumed the users group is usable and not empty.) This state does not look too consistent and in the best interest of the users to me, and might be just due to an unfortunate effect that the introduction of pam once had in debian. --- It's probably a matter that users can easiy learn how to use unix permissions effectively and most of the time (day to day) hasslefree. For admins its a case to be able to consistently set default umasks (even user specific through the GECOS feature, if they want users created during the time that pam did not support "usergroups" to keep their default umask.) For developers it is a small change in the default configuration and stating the (re)introduced behaviour in the release notes. (If desired, an an option or script to save a paricular umask to the GECOS settings of existing users could be supplied.) For users it may be one of the things that have never been as easily explained to them, how to make use of unix file permissions, hassle free. For a distribution its the user experience of doing easy ubuntu amoung users. For me, it once was a cloud clearing up and the sun comming out, showing how easy to use file permissions can be. -- pam_umask.so missing in common-session https://bugs.launchpad.net/bugs/253096 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
