sufficient account management checking for locally definedusers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Martin" == Martin Schwenke <martin@meltin.net> writes:

    Martin> Now for the bad news: initgroups() is called from the
    Martin> application (login/sshd) and not from PAM.  Now that's
    Martin> pretty crappy, because it means it can't be configured per
    Martin> application: I can't tell login to only look at local
    Martin> users...

    Martin> As far as I'm concerned the initgroups() call should
    Martin> happen in PAM so that a different implementation can be
    Martin> substituted.  That's what the 'P' in "PAM" is all about.
    Martin> The current design is broken.  I don't think I stand a
    Martin> strong chance of having that design changed, reimplemented
    Martin> and accepted upstream (even though I'm willing to do great
    Martin> chunks of it myself), so it's time to give up (or rely on
    Martin> an LD_PRELOAD hack to get to my root account...
    Martin> ummm... no!  :-)

Traditionally, PAM has not been responsible for credential
establishment for local credentials.  In particular, for many
applications, you don't want credentials established just because
authentication has happened.  For example, an imapd like Cyrus would
never want to establish credentials as a specific user.


But wait, there's pam_setcred, that evil hack that sort of snuck in
for some reason--perhaps because someone had heard of Kerberos and
didn't quite understand it, or perhaps because someone wanted to write
pam_group.  Now, we have pam_group (I think that's the right module),
which will add you to certain groups under certain conditions;
pam_krb5, which sets up network credentials, and many other modules.


Long term, I think having PAM evolve to handle credentials
establishment would be a net good; it would certainly help some of my
long-term projects and would better mirror some of the better parts of
the Windows security model.  (I don't think emulating Windows for the
sake of emulating Windows is good, but in this area I think they have
a better architecture than we currently do.)


Of course when you take things to their logical conclusion, PAM would
be responsible both for the setuid call *and* initgroups; I think
doing one without the other would be wrong.

Getting to that ideal world would be very difficult; I think the PAM
upstream, libc upstream and application writers would all disagree
with us.  We'd also need to think carefully about the API and
potentially change things and better define things such that PAM could
actually be responsible for user credential management.  But hey if
anyone ever wants to fight that battle, I'm certainly interested in
helping.


--Sam


P.S.  I haven't actually thought about what I'd think of a local
authentication only module in that universe.





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux