Am Dienstag 29 Juni 2010, 15:39:10 schrieb Josef Reidinger: > Ralf Haferkamp write: > > Am Montag 21 Juni 2010, 14:00:28 schrieb Josef Reidinger: > > > Hi, > > > because of new feature to support more authentication backend I > > > look more closer how we currently authenticate. Result is that it > > > works only for /etc/passwd. So I try to research how work > > > interesting world of pam and look again how works rpam which we > > > used in past. Rpam doesn't work for our appliance in previous > > > result, because it cannot read /etc/shadow. Only way how to avoid > > > it is to set suid, which is not acceptable. > > > > There is probably another possibility: "sssd". SSSD is a daemon that > > can be configured to act a proxy for pam authentication. In your > > case you could set up that system so that rpam would use pam_sss > > for authentication and forward the request to pam_unix2 (or > > whatever other PAM modules you want to use). sssd is running as > > root so it will have access to /etc/shadow. sssd has also some > > other nice features like caching and offline authentication. > > Additionally it offers native backends for doing LDAP and Kerberos > > (i.e. for LDAP and Kerberos you won't configure in proxy mode but > > use the native sssd backends through pam_sss). There of course > > other pam modules for which you wouldn't need to use sssd. E.g. > > when using winbind to authenticate against Active Directory. > > > > There are of course some drawbacks of sssd: > > - we don't ship it with SLES11-SP1, we will have it in 11.3 though. > > And > > > > I'd also like to see it in SLES11-SP2 (this hasn't be decided yet) > > Hi, thanks for info. Problem is that feature is requested for > appliance toolkit 1.1 which is based on SLE11SP1, so we cannot use > it. > > > - the "proxy" mode does only support very simple setups. For more > > complex > > > > PAM setups it won't be every userfriendly WRT to error handling > > IIRC. > > > > > So we use just unix2_chkpwd which is part of > > > pam_modules to allow pam to solve same problem as we have. So now > > > we use just unix2_chkpwd for result which of course doesn't work > > > for other authenticate backends. But for this purpose works good > > > rpam as pam can read from ldap, edir etc... Easy way how to solve > > > it is to revert patch which remove rpam usage, but I don't like > > > much that we must handle it. I think that it could be nice if > > > rpam if detect that if cannot read /etc/shadow then use > > > unix2_chkpwd itself instead our code. > > > > How would you want to detect that? You'd need to put knowledge into > > rpam which it shouldn't have (e.g. by trying to access /etc/shadow > > or reading the pam-configuration). I don't think that would be a > > good idea. > > In webyast we now try to authentificate using rpam and if it fail we > use unix2_chkpwd directly. For me purpose of rpam should be > authentification using pam, so from my point of view if pam can > authentificate againts local users, rpam also should do it even if it > doesn't run as root. Josef rpam doesn't seem to be different to any other pam-client in this regard. It's a well know fact that pam_unix2 (and some more pam-modules) need to run as root in order to work correctly.
-- Ralf -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
