Mailinglist Archive: yast-devel (34 mails)

< Previous Next >
Re: [yast-devel] Webyast and rpam
  • From: Ralf Haferkamp <rhafer@xxxxxxx>
  • Date: Tue, 29 Jun 2010 16:57:14 +0200
  • Message-id: <201006291657.15171.rhafer@xxxxxxx>
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: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >