[Guido Günther]
> should do the trick. The "sufficient pam_unix.so" makes sure you don't
> proceed to storing the password.
Right. I believe that is not going to work for the setup I am looking
at, because pam_group is needed and it is inserted as an Additional
entry leading to this configuration (without ccreds):
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_group.so
If I understand this correctly, using sufficient for pam_unix would
lead to pam_group never being called.
I use this pam-configs entry for pam_group:
Name: Group membership granted at login
Default: yes
Priority: 0
Auth-Type: Additional
Auth:
optional pam_group.so
> I haven't looked into pam-auth-update yet to check if something like
> this is feasable. If it isn't we should add pam-auth-update support
> to libpam-ccreds yet.
I suspect 'not' is missing from the last sentence, and if that is the
case I believe not providing such support in libpam-ccreds would be a
very bad idea given that pam-auth-update will be the method used to
configure pam.d entries for Squeeze. Providing a config for ccreds
will be the most efficient way to get feedback and improvements before
Squeeze is released, and essential to get libpam-ccreds working out of
the box for Squeeze.
And this issue is not really a big deal, given that the root password
hash already is available for the root user in /etc/shadow and having
it availalbe for the root user using cc_dump using a different
algorithm too is annoying but not really a serious problem. After
all, if someone already got unauthorized root access, getting access
to two hashes is a minor issue. :)
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
