[17189] in Kerberos_V5_Development
Re: gss_pname_to_uid: is that the right interface
daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Sep 20 22:35:31 2011
MIME-Version: 1.0
In-Reply-To: <1316559009.2684.549.camel@willson.li.ssimo.org>
Date: Tue, 20 Sep 2011 21:35:24 -0500
Message-ID: <CAK3OfOja-GNMCoCydGrOX330WqYpTpT_rRcaBZw8PD_59dRteA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Simo Sorce <simo@redhat.com>
Cc: lha@h5l.org, lukeh@padl.com, Sam Hartman <hartmans@mit.edu>,
krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Sep 20, 2011 at 5:50 PM, Simo Sorce <simo@redhat.com> wrote:> On Tue, 2011-09-20 at 16:11 -0500, Nico Williams wrote:>> I think this one's really just for compatibility with Solaris. I>> agree that putting UIDs in any of these APIs is a bad idea, but I'm>> not sure that the SSSD problem wouldn't exist for your proposed>> variant. If the problem for SSSD is one of timing, why couldn't that>> problem exist for *any* GSS version of krb5_aname_to_lname()?>>>> Any timing issues w.r.t. SSSD should be documented by RedHat and/or>> the mechanism implementor/vendor.>> We have an issue with OpenSSH doing getpwnam() before SSSD has a chance> of getting its hands on the MS-PAC (or in future the PAD with the POSIX> attributes). So avoiding getpw*() calss is a good idea.
Note that the same could have been said of PAM. IIRC I did some workon SunSSH to delay getpwnam() calls as much as possible (but it's beenseven or eight years now).
> If krb5_aname_to_lname() is implemented by using getpw() calls it has> the same kind of issues, but it doesn't need to. mapping principal name> to local name usually is not done through the NSS interface, while> getting the uid can only be done through that interface.
aname2lname() need not need any getpw*() calls, but who knows what aplugin might need.
Furthermore, what if you need to do self-credentialed LDAP or LSAlookups before you can complete a principal name to username mapping?It's conceivable. And if aname2lname() were pluggable, all the moreso.
What's bad about gss_pname_to_uid() is that it deals in UIDs, thus isinherently not portable. A gss_aname_to_lname() would be moreportable, but could still conceivably suffer from timing issues.
What would be best, IMO, is to have a way to pass the gss_name_t (andany delegated credentials, and maybe even the security context) toSSSD, then get the username from SSSD.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
