On Sun, Feb 13, 2011 at 02:31:42PM -0800, Steve Langasek wrote: > On Tue, Feb 08, 2011 at 04:27:40PM +1100, Craig Sanders wrote: > > > is there any reason why /etc/pam.d/common-session-noninteractive > > should load the pam_unix module? i.e. does it serve any useful > > purpose? [...] > > Hmm, the reason we do this is because it's Always Been That Way <tm>.
yeah, i figured it was something like that :) > When the split of common-session into common-session and > common-session-noninteractive was conceived, the kinds of modules I > had in mind were things like consolekit and ecryptfs, not pam_unix. yep, the split was (and still is) a good idea. > pam_unix had been in /etc/pam.d/common-session for years already and > no one had reported any bugs about this. But as you say, the value of > pam_unix as a session module is marginal, and possibly even less so > for the non-interactive cases. i think it's still useful for interactive sessions (it's good to have login & logout recorded in the logs), but just creates logfile noise for non-interactive sessions. > Before changing the unix profile, though, I'd like to see what the > consensus is on debian-devel. fair enough. it may turn out that it's actually useful (or even necessary) for some reason i haven't thought of. > > i've commented it out on my systems with no ill-effects, but that > > means i now no longer benefit pam-auth-update > > [...] > > This is probably woefully underdocumented, and still doesn't help > if what you really want is to enable only half of the profile in > question. mostly what i want is to not have non-interactive sessions fill my auth.log with "non-interesting" stuff, without losing the benefits of pam-auth-update. the simple way of doing that is for pam_unix not to be in common-session-noninteractive to start with (but you're waiting on consensus to see if that's actually a good idea or not). a more complicated way would be to have some method of configure pam-auth-update to 'blacklist' particular modules from particular common-* files. that's probably way more trouble to implement than it's worth....and unneeded complexity is a good way of introducing problems. for now, i'll settle for commenting it out in common-s-ni and live with the fact that it effectively disables pam-auth-update (and perhaps manually forcing an update and re-commenting it out every so often just to stop my systems from diverging too far from debian 'standard'), and hope that the default gets changed eventually. i.e. it would be nice if it happened some day, but it's far from a high-priority change. craig -- craig sanders <c...@taz.net.au> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
