[Pkg-shadow-devel] pam_env should be a session module

[Nicolas François]

Hello,

See the attached discussion on #debian-devel.

Currently, when root uses su, pam_env is not used (because pam_env is used
as an auth module, and pam_rootok is defined as sufficient earlier)

I think we should use pam_env as a session module (as upstream do).

Another solution would be to move the pam_env line before sufficient
pam_rootok.

Best Regards,
-- 
Nekral
-------------- next part --------------
00:51 < Sesse> vorlon: are you sure you fixed the problem with pam_env not reading /etc/environment?
00:51 < Sesse> vorlon: it's very much alive on a machine here, even after upgrading to the version that was supposed to fix it.
00:51 < vorlon> Sesse: yes; now it just borks instead if /etc/environment is missing.
00:52 < Sesse> vorlon: it's not missing, but it's definitely not read either
00:52 < Sesse> (according to strace)
00:52 < asuffield> Sesse: you did restart all the offending processes?
00:52 < vorlon> ok, well, everyone else agrees that it's fixed.
00:52 < Sesse> asuffield: it's on a fresh su
00:52 < Sesse> it reads pam_env.so into memory, then goes on
00:52 < Sesse> might it be that it's reading the old one?
00:53 < vorlon> not past an exec boundary
00:53 < Sesse> well, then the bug is still there.
00:53 < asuffield> only really a problem for login and xdm and shit, not su
00:54 < vorlon> are you sure that su *sets* the environment based on pam_env?
00:54 < vorlon> nm -Du /bin/su |grep env
00:54 < vorlon>          U getenv
00:54 < vorlon>          U pam_getenvlist
00:54 < vorlon> notable absences: putenv
00:55 < asuffield> putenv is broken shit
00:55 < asuffield> I doubt su uses it
00:55 < vorlon> you think it mangles environ directly?
00:55 < Sesse> well, /etc/pam.d/su contains pam_env.so
00:55 < asuffield> nah, execve()
00:55 < asuffield> it's the only safe way on posix, really
00:56 < vorlon> could be, then.
00:56 < vorlon> anyway, pam_env works fine for ssh; su doesn't do shit with it, and that's an su bug, not a pam_env bug.
00:56 -!- schultmc [n=schultmc at zealot.progeny.com] has quit ["Client exiting"]
00:56 < Sesse> well, ok
00:57 < Sesse> I'll have him restart his gdm
00:57 < Sesse> that should be sufficient, right?
00:57 < asuffield> with gdm? fuck knows
00:57 < asuffield> if it were xdm or kdm it would be
00:57 < asuffield> but gdm has some *impressive* crack
00:58 < vorlon> Sesse: ah, are you testing su by su'ing from root to another user?
00:59 < asuffield> oh, um, don't forget the hyphen
00:59 < Sesse> vorlon: hm, might actually be.
00:59 < Sesse> vorlon: he's restarting now, so we'll see if that helps :-)
00:59 < nekral_> vorlon: IIRC, su sets environ, according to pam_getenvlist
00:59 < Sesse> (he missed out and actually shut down his entire PC)
00:59 < vorlon> Sesse: yeah.  Check the order of the modules in /etc/pam.d/su, and check the word "sufficient" next to the module named "pam_rootok" :P
00:59 < vorlon> nekral_: ok, fair enough
00:59 < Sesse> vorlon: mm, point
00:59 < Sesse> vorlon: pam_env should perhaps be earlier?
01:00 < vorlon> Sesse: if you want it to be used when root su's to other accounts, yes
01:01 < Sesse> ok, it worked
01:03 < nekral_> vorlon: shouldn't pam_env be a session module?
01:03 < vorlon> nekral_: in fact, it *is* a session module... don't ask me why /etc/pam.d/su uses it as an auth module...
01:03 < asuffield> because it's wrong?
01:04 < asuffield> using a session module in auth will generally do precisely nothing
01:04 < asuffield> which is what it appears to be doing
01:04 < Sesse> so, it's a bug
01:04 < vorlon> actually, PAM will balk if the module doesn't provide the requisite hooks
01:04 < vorlon> but pam_env can be used as an auth or session module
01:04 < vorlon> or an authorization ("account") module :P
01:04 < Sesse> that sounds broken.
01:04 < asuffield> drugs! who implemented this insanity?
01:05 < asuffield> oh, pam core module, right
01:05 < vorlon> yeah, lots of early PAM stuff was broken because it inherited lots of "all we need is auth" from Solaris
01:05 < asuffield> hell, lots of pam stuff is just plain broken
01:06  * vorlon invites asuffield to replace it with BSD auth
01:06 < asuffield> just because it's crap does not justify making it worse :P
01:06 < vorlon> eh, how is BSD auth worse?
01:06 < asuffield> I dunno, but I'm sure it will be somehow
01:07 < vorlon> exec barrier between the application and each module?


01:09 < nekral_> BTW, could pam_env allow to set a different PATH for root/non-root?
01:10 < vorlon> hmm, could be.  How slow is exec() these days?
01:10 < vorlon> nekral_: yes, using /etc/security/pam_env.conf I think.
01:11 < nekral_> I can set PATH, but it will be the same whatever the user, no?
01:11 < vorlon> erm... yse
01:11 < vorlon> so instead you'd have to put two instances of pam_env in your config, pass a different config file to one of them, and switch on pam_rootok to decide which one to read