[Freeipa-devel] [PATCH] 1059 single CRL generator

[Martin Kosek]

On 10/05/2012 09:36 PM, Ade Lee wrote:
> On Fri, 2012-10-05 at 12:26 -0400, Simo Sorce wrote:
>> On Fri, 2012-10-05 at 12:19 -0400, Ade Lee wrote:
>>> On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote:
>>>> On 10/05/2012 10:59 AM, Martin Kosek wrote:
>>>>> On 10/04/2012 06:17 PM, Rob Crittenden wrote:
>>>>>> This changes the way IPA generates CRLs for new installs only.
>>>>>>
>>>>>> The first master installed is configured as the CRL generator. An entry is
>>>>>> added to cn=masters that designates it.
>>>>>>
>>>>>> When a replica is installed it queries this entry so it knows where to forward
>>>>>> CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will
>>>>>> return not found). It is possible to get a CRL directly from the clone CA via
>>>>>> http://<hostname>:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL
>>>>>>
>>>>>> rob
>>>>
>>>> ...
>>>>
>>>>> 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I
>>>>> always get 403 Forbidden error when trying to download CRL from the CRL master:
>>>>>
>>>>> # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin
>>>>> --2012-10-05 03:32:58--
>>>>> https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin
>>>>> Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120
>>>>> Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected.
>>>>> HTTP request sent, awaiting response... 403 Forbidden
>>>>> 2012-10-05 03:32:58 ERROR 403: Forbidden.
>>>>>
>>>>> I tracked the problem down to too strict permission on /var/lib/pki-ca
>>>>> directory which is being published by httpd which does not have access to it:
>>>>>
>>>>> # ll /var/lib/pki-ca
>>>>>
>>>>> drwxrwx---. 11 pkiuser pkiuser 4096 Oct  5 03:00 pki-ca
>>>>>
>>>>> When I fixed the permission:
>>>>> # chmod o+x /var/lib/pki-ca/
>>>>>
>>>>> I was able to get pass the Forbidden error and actually retrieved the CRL.
>>>>> Adding Ade on CC list to follow on this permission issue.
>>>>
>>>> FYI - I filed a ticket for this issue:
>>>> https://fedorahosted.org/freeipa/ticket/3144
>>>>
>>>> I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for
>>>> /var/lib/pki-ca/publish/
>>>>
>>>
>>> Sorry, but why do you need permissions on /var/lib/pki-ca?  Aren't
>>> permissions on /var/lib/pki-ca/publish sufficient?
>>
>> Ade,
>> on unix filesystems you cannot traverse a directory path if you do not
>> have permission all the way through.
>> If 'others' can't access /var/lib/pki-ca they will never even reach the
>> point where they can see that they have access to a subdirectory.
>> The very minimum permission you need to be able to traverse directories
>> is to have the 'traverse' (x) bit set. (note that you do not need the
>> read (r) bit set just to traverse).
>>
> 
> I suspected as much, but wanted to confirm.  
> 
> The decision to publish the CRL to /var/lib/pki-ca/publish is an IPA
> deployment decision.  This is a directory that is created by the IPA
> install scripts.  Other folks who deploy Dogtag may choose to publish
> elsewhere - like under /var/www/... for instance.  A location outside of
> the pki-ca tree seems like a safer option to me, rather than allowing
> "other" to step through /var/lib/pki-ca ...
> 
> In any case, if you do decide to leave the publishing directory in that
> location, you will need to also set the +x permissions for other
> on /var/lib/pki-ca in the IPA install scripts.
> 
> Ade

Ok, I see 2 possible solutions here:

1) Add X permission to others all along the way to /var/lib/pki-ca/publish
(dogtag9) or /var/lib/pki/pki-tomcat/ca/publish (dogtag10).

2) Move CRL publishing directory to tree controlled by IPA as Ade suggested.
/var/lib/ipa/pki-ca/publish
looks as a good target to me.

I think this is a long-term solution than (mis)using pki-ca directory structure
- which may change along the way as it did with dogtag10. Plus, we would no
longer get SELinux warning during RPM upgrades when it cannot find
dogtag9/dogtag10 path respectively.

If we go with option 2), I wonder if it is doable in IPA 3.0 timeframe. I plan
to try to poke at it today and see how it goes.

Martin