On 2015-05-28 17:10, Simo Sorce wrote:
> On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote:
>> On 2015-05-28 16:53, Simo Sorce wrote:
>>> We can't have 2 different keytabs with the same principal name.
>>> If we need privilege separation we'll have to work on integrating
>>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
>>> of both the framework, the proxy, and apache itself.
>> I had a different principal like KDCPROXY/fqdn@realm in mind.
>>> Although to be honest I do not see why the proxy need access to the
>>> keytab at all, can we simply run it as a wsgi application under a
>>> different user and prevent it from accessing the apache keytab at all ?
>> Yes, mod_wsgi is able to run a WSGI app as a different user:
>> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
>> A different user needs another location for the ccache and perhaps
>> additional SELinux rules.
> If you are using the keytab only to acquire credentials to access ldap
> you could use a memory ccache and not have to deal with locations:
> KRB5CCNAME=MEMORY:kdcproxy_<random_number>

Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on
older versions of RHEL, too?

>>> What do we need the keytab for ?
>>> Is it just in order to authenticate and read if the service is enabled ?
>>> Can we make that information available anonymously ?
>> Yes, the information is not available for anon bind. It doesn't feel
>> right to disclose the settings to the public.
> Another option is to use ldapi and external auth, I forgot if we allow
> automatic binding for no-root users though.

No, been there, tried it, failed. It works as root but not as Apache
user or my test user.


Attachment: signature.asc
Description: OpenPGP digital signature

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to