[Bug 253096] Re: pam_umask.so missing in common-session
The following wiki page now contains more information and ties together related bugs. https://wiki.ubuntu.com/MultiUserManagement -- 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
[Bug 253096] Re: pam_umask.so missing in common-session
Please include a pam-auth-profile to support the user private group theme. So that a debconf setting will put the line "session optional pam_umask.so usergroups" into the common-session config. -- 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
[Bug 253096] Re: pam_umask.so missing in common-session
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//writings /home/share//readings compare to /home//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 /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 u
[Bug 253096] Re: pam_umask.so missing in common-session
> The example came from the pam_umask man page, maybe I had some typo. Oh, sorry; I was apparently looking at an old, superseded pam_umask module in the archive, and hadn't remembered that there's now a pam_umask module included in Linux-PAM. The manpage says this about the 'usergroups' option: If the user is not root, and the user ID is equal to the group ID, and the username is the same as primary group name, the umask group bits are set to be the same as owner bits (examples: 022 -> 002, 077 -> 007). This would result in inconsistent umask settings anyway, because there is no guarantee that the gid of a usergroup will match the uid of the user: some users would get 022, others would get 002. So that would need to be fixed for Ubuntu use, and I don't know that this is a change that would be accepted upstream since other distros seem to have differing expectations for usergroups. > There is some history why this bug should be fixed. It is a regression that is now easy to fix. It is not a regression within Ubuntu; there has never been a non-PAM release of Ubuntu, and Debian has been using PAM for 9 years. From this perspective, changing the system default umask would be a regression, because many users today have no idea what a umask is yet may be dependent on this setting for their security - for instance, when creating files in sgid directories that they /don't/ intend to be readable by the group. These subtle semantic changes are such that I don't think it would ever be a good idea to relax the default umask. I am setting the bug state back to 'new', in any case, because I'm no longer sure that session umasks are set correctly in all cases since some sessions don't involve spawning a login shell. ** Changed in: pam (Ubuntu) Status: Won't Fix => New -- 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
[Bug 253096] Re: pam_umask.so missing in common-session
FYI here is a summary of a Sep 2005 discussion in debian, by now it may be added that, as pam_umask supports the "usergroups" feature, it is no longer neccessary to set the umask to 002 for all users, with pam_umask's "usergroups" feature it will check if users are in a private primary user group. (Debian/Ubuntu has allways used private user groups by default, the switch to pam only broke adequate umask adjustment. Those that are not familiar with the merrits of private user groups for collaborating with other users may have a look at explanation supplied with Bug #252351) It might be desireable to supply a patch to pam_umask to not only fetch UMASK but also the USERGROUPS_ENAB setting from login.defs (or /etc/default/login), then "usergroups" does not have to be set in common-session. Here is the report about the related debian discussion: Christian Perrier <[EMAIL PROTECTED]> wrote: > >(adding the shadow maintainers list to the CC, and therefore keeping a >whole citation, sorry fot this) > >> Summary for technical comittee: setting the umask >> >> Inconsistent umask settings; user private groups concept requires umask 002 >> to >> work. >> Relates to #248140 #248150 #314539 >> >> >> Please successively reasign to base-files (and other packages containing >> umask >> settings), login and libpam-umask packages to resolve the situation. >> >> >> Debian ships defaulting to put newly created users into private primary >> groups. The so called User Private Group (UPG) concept allows easy access >> right management for users. In sgid group-directories access rights of files >> can be set correctly automaticly. It is proven to work fine. >> >> Even though UPGs are the default in debian, they are not set up to work >> properly. The umask is currently set at different places and to conflicting >> values. The result is that the settings to 002 are in most cases not active. >> >> >> CURRENT SITUATION >> >> The settings in /etc/login.defs do reflect the use of UPGs and are adjusted >> to >> generate the correct umask: >> >> # Enable setting of the umask group bits to be the same as owner bits >> # (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is >> # the same as gid, and username is the same as the primary group name. >> # >> # This also enables userdel to remove user groups if no members exist. >> # >> USERGROUPS_ENAB yes >> >> However: >> a) This login.def functionality is not active on systems with PAM (now >> standard in debian). And the pam_umask funktionality is not part of the base >> system. >> >> b) The umask gets overwritten in shells that source rc files like >> /etc/profile >> which ships with an umask line. >> >> >> SUGGESTED SOLUTION >> >> 1) remove/comment out any umask settings in all shell configuration files >> shiped with debian (i.e. /etc/profile) and add a comments >> that /etc/login.defs or better pam_umask ist the right place for global >> umask >> setting. >> It might be /etc/default/login (LSB?) now, pam_umask looks at both. Setting umask in common-session is only to override user specific GECOS settings. >> 2) In /etc/login.defs correctly move all settings that are overridden by PAM >> below that comment (i.e. USERGROUPS_ENAB) and vice versa[1]. Set the umask >> to 002 for the case that libpam-umask is not installed, but point the admin >> to libpam-umask and the right file for the umask setting. >> The historical UMASK 022 may be set (uncommented again) if /etc/default/login is not adopted, pam_umask support for usergroups (man pam_umask) should be mentioned. >> 3) Add libpam-umask to the base system. And enable the default umask of 002 >> as >> described in the README. pam_umask.so is now part of regular libpam-modules and looks for umask settings in starndard places. No need to supply an override umask in common-session. >> >> >> --- >> >> The articulated reason for closing #248140 has been that if an umask of 002 >> would be active instead of the 022 this could lend to unexpected behaviour. >> The example given was that when copying with scp to systems without UPGs >> might unexpectedly expose files to write access. >> >> However scp should nomaly respect the umask on the target system. >> >> Only when explicitly using "scp -p" (preserving permissions) that might not >> be >> the case. But when copying files between systems with explicity using >> switches like these, it seems the user has to be aware of possible >> implications and inconsistencies in user and group IDs anyway. With "scp -p" >> as a normal user the copy might belong to the destination user and its >> primary group, done as root numerical UIDs taken from other systems may >> always belong to different users. >> >> The possibly of users (accidentially) having scp aliased to "scp -p" may >> seem >> a little far fetched to warrant shiping debian with a non-working user >> private group setup by default. >> > >All this seems to
[Bug 253096] Re: pam_umask.so missing in common-session
Hello Steve, thank you for improving ubuntu. The example came from the pam_umask man page, maybe I had some typo. There is some history why this bug should be fixed. It is a regression that is now easy to fix. Before pam was introduced "login" provided the central point to set the UMASK value in login.defs and also containded the USERGROUPS_ENAB checking feature. The switch to pam was made before pam supported this functionality. Since umask is an important parameter that people need to have set, they began to set umask in shell rc scripts, xsessions, ssh_config, some display mangers even hardcoded the umask etc. (And some of this had to be done to face the regression in day to day use.) Finaly pam_umask.so reintroduced the functionality in pam and has now been merged from its own package (pam-umask) into the libpam-modules upstream. From the pam-umask package description: This package is useful to ensure that users' umasks are set consistently whether their session is initiated by login, SSH, a display manager for the X Window System, or some other means. -- 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
[Bug 253096] Re: pam_umask.so missing in common-session
Thank you for taking the time to report this bug and help to improve Ubuntu. There is nothing dynamic about what umask value that should be used for a given user, and there are already well-established means of setting the umask for a session (which will only be further confused if we add another method on top of that), so this is not a change that Ubuntu should adopt. It's possible that there are places where a wrong umask is being set by default; those would be bugs, and should be fixed, but they are not bugs in pam, and should not be worked around by adding complexity to the default pam config. Also, I cannot corroborate your statement that setting umasks by the usual method doesn't work for login sessions. It certainly does for me. You may want to provide more detail about your use case. The example syntax you gave is also invalid. The pam_umask module in intrepid does not recognize a 'usergroups' option. ** Changed in: pam (Ubuntu) Assignee: (unassigned) => Steve Langasek (vorlon) Status: New => Won't Fix -- 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
[Bug 253096] Re: pam_umask.so missing in common-session
Oh, the problem with the current state is that umask is set all over the place in shell config files, xsessions, and do not work for ssh logins for example. -- 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
