[Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user

[Alexander Bokovoy]

On Wed, 18 Jul 2012, Simo Sorce wrote:
>On Wed, 2012-07-18 at 16:19 +0300, Alexander Bokovoy wrote:
>> On Wed, 18 Jul 2012, Rob Crittenden wrote:
>> >Alexander Bokovoy wrote:
>> >>On Tue, 17 Jul 2012, Rob Crittenden wrote:
>> >>>Alexander Bokovoy wrote:
>> >>>>On Fri, 13 Jul 2012, Alexander Bokovoy wrote:
>> >>>>>Hi,
>> >>>>>
>> >>>>>when adding AD trusts support, we need to ensure we have valid kerberos
>> >>>>>ticket of the user from 'admins' group or otherwise appropriate ACIs
>> >>>>>will not be granted.
>> >>>>>
>> >>>>>This patch introduces a check for that. We already check if
>> >>>>>ipa-adtrust-install is run by root so this complements existing checks.
>> >>>>>
>> >>>>>https://fedorahosted.org/freeipa/ticket/2815
>> >>>>After discussing on IRC with Simo and Rob, we came to conclusion that it
>> >>>>is possible to switch to LDAPI and autobind feature of dirsrv for
>> >>>>authentication and remove requirement for Directory Manager credentials
>> >>>>altogether.
>> >>>>
>> >>>>Updated patch makes use of LDAPI + autobind under root privileges to map
>> >>>>automatically to Directory Manager privileges in dirsrv. Additionally it
>> >>>>ensures we have Kerberos credentials to fetch keytab with CIFS service
>> >>>>key.
>> >>>>
>> >>>>Service._ldap_mod() is extended to switch to autobind when self.ldapi is
>> >>>>set to True and we are running as root.
>> >>>>
>> >>>>For those interested in why ACIError is mapped to 'outdated Kerberos
>> >>>>credentials' error message, this is because we'll get ACIError for 'ipa
>> >>>>user-show <uid>' command when authenticated by the Kerberos credentials
>> >>>>for <uid> in a default ccache only when Kerberos credentials are
>> >>>>stale --
>> >>>>either belong to a user that was removed or to a previous IPA install
>> >>>>that was wiped before reinstalling. The latter is how I discovered
>> >>>>this case. :)
>> >>>
>> >>>I think that this should raise an exception if one tries to use ldapi,
>> >>>doesn't provide the DM password and is not root. Otherwise it won't
>> >>>authenticate at all.
>> >>This is not exactly true.
>> >>
>> >>$ id
>> >>uid=757000001(abokovoy) gid=757000001(abokovoy) groups=757000001(abokovoy)
>> >>context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> >>
>> >>$ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*'
>> >> >/dev/null
>> >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base )
>> >>SASL/EXTERNAL authentication started
>> >>ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
>> >>     additional info: SASL EXTERNAL bind requires an SSL connection
>> >>
>> >>$ ldapsearch -vvv -Y GSSAPI -H
>> >>ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null
>> >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base )
>> >>SASL/GSSAPI authentication started
>> >>SASL username: abokovoy at IPA.LOCAL
>> >>SASL SSF: 56
>> >>SASL data security layer installed.
>> >>filter: (objectclass=*)
>> >>requesting: *
>> >>So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI
>> >>when non-root and no dm_password regardless of self.ldapi, this would
>> >>extend previously available logic to following:
>> >>
>> >>- ldapi: use -H ldapi://url instead of -h hostname
>> >>- dm_password: add Directory Manager auth
>> >>- root without dm_password: use autobind
>> >>- non-root without dm_password: use GSSAPI
>> >>
>> >>>In reality, I think all this service code always runs as root, so it
>> >>>may be a moot point, but this code is kinda convoluted.
>> >>Yep.
>> >>
>> >
>> >Sorry, I didn't mean this in general, but this code is going to
>> >result in no auth being used which is going to fail. So rather than
>> >failing with some no auth error we either enforce that Service is
>> >executed as root or raise an exception in this auth code. In other
>> >words, if we know something isn't going to work before we try it, we
>> >should fail with a more friendly error.
>> What the code did before in such case (no DM, non-root, non-ldapi) is to
>> use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest
>> patch (-2) expands this also to (no DM, non-root, ldapi) case.
>>
>> However, one case is not covered yet: no DM, root, non-ldapi. We either
>> can try -Y GSSAPI here as well or raise exception. I'd prefer the
>> former.
>
>When in doubt always try GSSAPI please.
This gets us back to my patch (-1) because
-            auth_parms = ["-Y", "GSSAPI"]
+            auth_params = []
+            if not (os.getegid() == 0 and self.ldapi):
+                auth_parms = ["-Y", "GSSAPI"]
covers both (no DM, root, non-ldapi) and (no DM, non-root, non-ldapi)

-- 
/ Alexander Bokovoy