[17203] in Kerberos_V5_Development
Re: gss_pname_to_uid: is that the right interface
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Sep 22 11:33:51 2011
MIME-Version: 1.0
In-Reply-To: <D034B791-BD05-4EF4-A844-33069CD2B8A4@h5l.org>
Date: Thu, 22 Sep 2011 10:33:43 -0500
Message-ID: <CAK3OfOiKcAT5FNgqG=fynZgWM+m=p018z8oLrkUJKCEM+5hzAA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= <lha@h5l.org>
Cc: Danilo Almeida <dalmeida@mit.edu>, Sam Hartman <hartmans@mit.edu>,
krbdev@mit.edu, Simo Sorce <simo@redhat.com>, lukeh@padl.com
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Sep 22, 2011 at 9:18 AM, Love Hörnquist Åstrand <lha@h5l.org> wrote:> 22 sep 2011 kl. 11:08 skrev Danilo Almeida:>> Adding OS authorization notions such as username or uid as a new calls into>> GSSAPI seems like a really bad idea
I agree that a well-known name extension should do. However, thisaname2localname thing so long precedes naming extensions, andlocalnames are so pervasive, that it's worth having this as afirst-class feature.
That said, I much prefer that the OS provide an integratedauthorization facility. This means passing GSS objects to PAM, SSSD,etcetera, so that PACs, PADs, and so on can be extracted and used ifpresent and relevant.
In other words, I agree with this:
> Not having it creates security bugs, there are plenty examples where people do gss_display_name() and then cut the string at the @ and call it a username.
So much so that maybe we should have multiple alternate displaysyntaxes for each mech & name type, and pick one randomly ingss_display_name()! Yes, I'm kidding, mostly :)
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
