Hi Everyone,
Ping. This submission has received no further comments in a week.
(I have included the DEV mailing list in the reply since it seems more
appropriate to discuss a patch submission there than on the USERS list.)
Gavin.
On 24/07/2009, at 04:04 , Alec Kloss wrote:
> On 2009-07-23 15:30, Lieven Govaerts wrote:
>> On Sat, Mar 21, 2009 at 3:06 AM, Alec
>> Kloss<alec-dated-1238029604.c45de2_at_setfilepointer.com> wrote:
> [chop]
>>>
>>> Please see attached patch. It works against 1.6.0 and trunk r36738.
>>
>>> [[[
>>>
>>> Add option cross-realm support to cyrus_auth.c. Adds three
>>> boolean configuration entries in the [sasl] section:
>>>
>>> enable-cross-realm: set to enable cross-realm support
>>> remove-local-realm: set to true to remove the local realm
>>> from a user name, false to keep the realm on a local user.
>>> Defaults to !enable-cross-realm
>>> remove-remote-realm: set to true to remove the realm of a remote
>>> user. This is a potential security hazard and should not
>>> be enabled unless you're confident all realms are trustworthy.
>>>
>>> ]]]
>>
>> Why do we need those three flags exactly? Can we not select a safe
>> default?
>>
>> We don't seem to need them for kerberos over http (ra_neon)?
>>
>> Lieven
>>
>
> Short story:
>
> I think that these options are necessary for svnserve to stay
> consistent with its current behavior *and* allow it to be
> configured the way an administrator in a cross-realm environment
> would want it.
>
> Long story:
>
> The safe default is to enable cross realm and never strip the realm
> name. Unfortunately, the current implementation disables cross
> realm and always strips the realm. If you enable cross-realm by
> default and start including the realm, you break everyone's
> existing authz files. If you enable cross-realm and still strip
> the realm, you're created a potential security problem. If you
> stop stripping the realm, everyone's authz files will break when
> users start showing up with @REALM on them. I felt the flags and
> their defaults were closest to what an administrator would want for
> the following reasons:
>
> 1. Administrators of simple configurations don't have to worry
> about any of this cross-realm stuff.
>
> 2. Administrators who need cross-realm can flip a single knob,
> enable-cross-realm to make cross-realm work the way they'd expect.
>
> 3. Administrators who are migrating from a single realm to multiple
> realms can set enable-cross-realm and remove-local-realm. This
> keeps the existing authz file working and they can grant access to
> users from remote realms easily.
>
> 4. Administrators who are extremly trusting or have full control
> over the administration of all realms they have cross-realm trust
> with can set remove-local-realm and remove-remote-realm to use only
> usernames and never realms for authenticating users.
>
>
> Even longer story:
>
> You're almost talking apples and oranges. Nothing in Subversion
> uses plain Kerberos. Over HTTP, Subversion uses SPNEGO (aka
> Negotiate) which happens to normally be backed with Kerberos, and
> svn protocol uses SASL, which supports GSSAPI backed by Kerberos.
>
> In the end though, it is all Kerberos doing the heavy lifting, even
> though Subversion can't really tell that because the Kerberos is
> wrapped up in SPNEGO on http:// or SASL on svn://. Also note that
> ra_neon is the client half of the connection to a server which is
> using mod_auth_kerb, and svnserve is the server half of the
> connection from a subversion client. The more analogous part of
> the connection is mod_auth_kerb, not ra_neon.
>
> Here's the config info for modauthkerb:
>
> http://modauthkerb.sourceforge.net/configure.html
>
> This documentation is a little out of date; in 5.4 there is an
> option, KrbLocalUserMapping, which when turned on (not recommended)
> calls krb5_aname_to_localname. svnserve, right now, always
> disables cross-realm and always does roughly what
> krb5_aname_to_localname does, which is to strip the realm off the
> authenticated name. So, mod_auth_kerb always enables cross-realm,
> so it doesn't have a knob for it. It has a knob like
> remove-local-realm, and then it doesn't seem to have a knob like
> remove-remote-realm, probably because it seems like a bad idea,
> although people do ask for it. If you'd like to simplify the patch
> and get rid of remoe-remote-realm, I'm all for it. If you'd like
> to simplify the patch more and remove the remove-local-realm option
> and change the code to never remove the local realm, I'm okay with
> it, but you'll annoy lots of people when them upgrade and have to
> re-write their authz files. Removing the local-realm by default
> and not providing a config entry to change it is probably forcing
> administrators into a potentially unwise security situation.
>
>
> Hope that helps. Let me know if you have more questions or other
> ideas.
>
> --
> Alec.Kloss_at_oracle.com Oracle Middleware
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2379363
Received on 2009-08-03 02:08:22 CEST