The ebuilds for samba and the shadow password suite (and perhaps others) ignore the USE flags for pam. Regardless of whether '-pam' or 'pam' is in the USE flags, support is built for pam.
Az, Donny, John has a point -- is this something we can easily rectify?
I do not see the use of compiling shadow without pam (as he have it installed anyhow), because stuff like chsh, chage etc needs extra passwd's etc. Also, I will only consider this if somebody (few people) build whole system + kde/gnome with shadow like this.
i think it'll be ok for SAMBA. i'll look into this as time allows. not a big priority.
I have built multiple systems with kde and gnome, with shadow not linked against libpam. Everything works just fine, I don't know what you're talking about.
Do the following as your user (with shadown not compiled against pam): ------------------------------- $ chage azarah chage: permission denied $ chage -l azarah Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Apr 06, 2002 Password Expires: Never Password Inactive: Never Account Expires: Never $ chage -l root chage: permission denied
jm@impulse jm $ ldd /usr/bin/chage libcrypt.so.1 => /lib/libcrypt.so.1 (0x40020000) libcrack.so.2 => /usr/lib/libcrack.so.2 (0x4004e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) jm@impulse jm $ chage jm chage: permission denied jm@impulse jm $ chage -l jm Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Jan 06, 2003 Password Expires: Never Password Inactive: Never Account Expires: Never jm@impulse jm $ chage root chage: permission denied jm@impulse jm $ Appears to behave the same way. Pam absolutely does not provide any critical features for system operation or system administration for systems which use password authentication, that shadow cannot otherwise be set up to do without compiling it against libpam. This is why I ask you to make pam support optional.
Ok, ok :P Ill change after 1.4 if ok this side.
Created attachment 7111 [details] util linux ebuild
Created attachment 7112 [details] shadow ebuild
Created attachment 7113 [details] xfree ebuild
Created attachment 7114 [details] fixed xfree site.dev
Latest xfree versions already have pam optional.
Created attachment 19275 [details, diff] Pamless shadow diff
Quote of Azarah in mail. ------------------------------------------------------------------------ *) I do not like to leave /bin/login dangling out there. Method will have to comment if they had any issues, but especially with a non profile setup where two stuff can provide an critical item as login, we could have major breakage if the user decide to switch from or to pam. a) It might be an good idea to integrade pam-login with shadow ... b) Add a virtual for login. Problem though with this approach, is that last time I checked, portage did not handle a change in virtuals properly. Also, can you have something like: PROVIDE="pam? ( virtual/login )" for pam-login and: PROVIDE="!pam? ( virtual/login )" for shadow ? To be truly honest, last time I checked, this was not supported, but I do not know. *) The current /bin/login from shadow have a nasty bug if using it with pam - might want to verify that it do not exist in the pam-less one. Spider should be able to add more about the shadow_login/pam bug ... ------------------------------------------------------------------------
I'd like it if somebody from the pam team could help resolve/finalize how login should be handled (patches in portage preferred). Not having a pamless support in shadow is a real show stopper for those of us that are trying to support pamless profiles.
I'm starting to wonder if anybody on the pam team even checks mail, I'd really like some feedback here. This bug is the only thing holding up and blocking our profile from working.
I dont see solar addressing any of the points in the Azarah email snip. I do see too much attitude, which I dont appreciate. If I had any bright ideas, I would have put them in here.
i'm with woodchip on this. until the issues that azarah points out are solved in some fashion, i don't see much happening on this. we do definetly listen, just we don't respond unless we have positive input.
Well the feedback I was looking for is how would pam-bugs@ like to move forward with this and was wondering via the virtuals can we safely ensure the end user will have pam-login blocked if they have built shadow without +pam enabled. I dont see how this could be done at this time. Ok so it seems you want the "show me the code solution" which is fine. So in my tests here with PROVIDE="pam? ( virtual/login )" show this to be a problem and will corrupt the /var/cache/edb/virtual file. provides just don't seem to understand !?() So it sounds like our only option here is to merge pam-login into shadow. I can get started on this if need be (do you really want a non pam-bugs@ guy handling this?) in the next day or two, unless pam-bugs@ had any objections with reasons. Note: Donny nobody is giving attitude here(please dont read into that way), we are just trying to make forward progress. We got zhen is asking us on nearly a bi/tri daily basis whats going on with the shadow pkg.
There is no need for a virtual, this can be implemented nearly in place and without any changes to the pam structure. If a user has USE="-pam" then pam isn't installed (and pam-login), then the shadow ebuild will see USE="-pam" and not delete login. The root issue isn't there because we aren't using shadow login with pam, and there is always a login whether the user has USE="pam" or USE="-pam". This is the correct way to move this forward and I think it should be done in a week unless there is a substantive objection
> There is no need for a virtual, this can be implemented nearly > in place and without any changes to the pam structure. If a > user has USE="-pam" then pam isn't installed (and pam-login), > then the shadow ebuild will see USE="-pam" and not delete > login. The root issue isn't there because we aren't using > shadow login with pam, and there is always a login whether the > user has USE="pam" or USE="-pam". This is the correct way to > move this forward and I think it should be done in a week > unless there is a substantive objection Hmm, what precisely is preventing this from being implemented in place just as Joshua has stated above? I've been running Gentoo servers without pam (by modifying the profile and appropriate ebuilds in the same manner proposed) for nearly two years now and have seen no ill side effects as a result. The reason for not using pam? We use some custom nsswitch stuff, and pam would just be an extra unecessary layer. Why is there such a worry about the user switching to and from pam on a system wide basis? People aren't going to be switching between pam and non-pam like they would a text editor or even a bootloader. Using or not using pam is something you decide when you initially build the system. I daresay that if one were to attempt to switch from pam to non pam or visa-versa on a running system, one would have a lot more to worry about than two packages sharing /bin/login. A lot of things would probably break and have to be rebuilt because of pam library dependencies. It'd be akin to downgrading glibc, or something. For this reason, I agree with Joshua that a virtual isn't really necessary and that this is something worth implementing in place.
Nevermind, with the wonderful addition of stacked profiles I can remove pam/pam-login from the system profile relatively cleanly, and most of the offending ebuilds have been corrected.
can this be closed now?
As far as I know, this is fixed. The stacked profiles allow for a fairly elegant solution.
Yes. Please close as fixed. login/shadow with USE +pam || -pam seems to be handled everywhere correctly now.
closing
