[Pkg-shadow-devel] Re: {user,group}{add,mod,del} now PAMified

[Steve Langasek]

Hi Nicolas,

On Mon, Nov 07, 2005 at 01:21:43AM +0100, Nicolas François wrote:

> This is related to the discussion on #shadow.
> (I've read the backlog of last Friday).

> Here are some reasons I can see for the PAMification of
> {user,group}{add,mod,del} (and also others: chage chfn chsh newusers).

I have no objections to the use of PAM for chage/chfn/chsh; these are all
sgid/suid applications which provide services to non-privileged users, so it
is *expected* that PAM would be used for these services on Debian.

The question is {user,group}{add,mod,del} only, which are not suid-root and
should not be.

> These reasons are not really strong, and if there is a stronger reason for
> reverting this, we can revert.

> (I also add reasons to minimize these points)

>  * I think upstream uses the PAMified version of the shadow utilities. So
>    this code path is probably more maintained.

I don't believe this reason applies to the tools in question; the equivalent
non-PAM codepath for these tools requires zero lines of code.

>  * There is (or may be) a problem with the build system with the mix of
>    PAMified and non-PAMified utilities: Some functions of the lib or
>    libmisc directories difer when USE_PAM is set, and thus just adding
>    #udef USE_PAM at the top of the non-PAMified utilities is not optimal
>    (we can of course build twice and pick up the utilities we want from
>    the non-PAMified build)

This doesn't sound like something that warrants making configuration more
complicated for users, IMHO...

>  * The number of /etc/login.defs variables was reduced.

Please explain.  The default PAM configs for {user,group}{add,mod,del} are
complete no-ops.

> Steve, I'm not sure why you wish to revert to the non-PAMified versions.

Because I can't figure out what this PAM support is actually good for in the
real world, and all other things being equal, the simpler design is always
better.  So far, all of the use cases I've heard suggested for PAM support
in these particular tools are AFAICT entirely theoretical.

> If the reason is the number of /etc/pam.d files, we could merge some of
> them, and use a "shadow-utils" service

Yes, that's one factor.

> (the {user,group}{add,mod,del}, chage, chfn, chsh, and newusers PAM
> service files are identical).

No, chfn and chsh (the useful ones :) are *not* identical to the others...

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20051107/6aaceb2b/attachment.pgp