Bug 996581

Summary: When getcert cannot create the key or certificate, the error should state permission denied
Product: Red Hat Enterprise Linux 7 Reporter: Martin Kosek <mkosek>
Component: certmongerAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Kaleem <ksiddiqu>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: abokovoy, adingman, dpal, jgalipea, jpazdziora, mkosek, mnavrati, nalin, nsoman, parsonsa, tbabej
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: certmonger-0.68-1.el7 Doc Type: Known Issue
Doc Text:
The directory containing a private key or certificate can have an incorrect SELinux context. As a consequence, the ipa-getcert request -k command fails, and an unhelpful error message is displayed. To work around this problem, set the SELinux context on the directory containing the certificate and the key to cert_t. You can resubmit an existing certificate request by running the ipa-getcert resubmit -i <Request ID> command.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 10:02:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Martin Kosek 2013-08-13 13:22:58 UTC
This was reported by Jan Pazdziora in FreeIPA Trac:
https://fedorahosted.org/freeipa/ticket/3851

Description of problem:

When I run

ipa-getcert request -k /etc/the.key -f /etc/the.crt
the request result is

Request ID '20130808110311':
	status: NEED_KEY_PAIR
	stuck: no
	key pair storage: type=FILE,location='/etc/the.key'
	certificate: type=FILE,location='/etc/the.crt'
	CA: IPA
	issuer: 
	subject: 
	expires: unknown
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
The problem is caused by AVC denial:

type=AVC msg=audit(1375959791.139:612): avc:  denied  { write } for  pid=11561 comm="certmonger" name="etc" dev="dm-1" ino=786433 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir
It would be good if the status was clearer about the cause of the problem (permission) and maybe some additional client-error value had some details about the action that failed.

When the key can be written but the certificate cannot, the status is NEED_TO_SAVE_CERT -- again, it should be more specific about the fact that it already tried to save the certificate, that the operation failed, and why it failed.

In fact, is it correct that in these situations, the stuck: no is there -- shouldn't it be yes?

Comment 1 Nalin Dahyabhai 2013-08-29 19:29:09 UTC
Please check if development snapshots which identify as version 0.68 or higher handle this correctly.  If so, we can pull it in.

Comment 2 Martin Kosek 2013-09-05 14:15:21 UTC
Jan is the right person to ask.

Comment 3 Jan Pazdziora 2013-09-06 01:37:00 UTC
Where do I get the development snapshots from?

Comment 4 Nalin Dahyabhai 2013-09-06 16:06:21 UTC
(In reply to Jan Pazdziora from comment #3)
> Where do I get the development snapshots from?

You can rebuild Fedora 21's 0.68-1 package or grab the upstream tarball and use 'rpmbuild -ts' and mock, or 'rpmbuild -tb'.

Comment 7 Kaleem 2014-01-29 11:46:31 UTC
I tried with latest certmonger build and found this following message on console if correct selinux permission not set on directory where key or cert is going to be generated.

[root@rhel70-client ~]# ipa-getcert request -k /tmp/cert/the.key -f /tmp/cert/the.crt
The parent of location "/tmp/cert/the.crt" must be a valid directory.
[root@rhel70-client ~]#

I think error message here still not very clear.

certmonger version:
===================
[root@rhel70-client ~]# rpm -q certmonger
certmonger-0.70-1.el7.x86_64
[root@rhel70-client ~]#

steps performed:
================
[root@rhel70-client ~]# mkdir /tmp/cert
[root@rhel70-client ~]# ipa-getcert request -k /tmp/cert/the.key -f /tmp/cert/the.crt
The parent of location "/tmp/cert/the.crt" must be a valid directory.
[root@rhel70-client ~]# chcon -t cert_t /tmp/cert/
[root@rhel70-client ~]# ls -laZ /tmp/cert/
drwxr-xr-x. root root unconfined_u:object_r:cert_t:s0  .
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       ..
[root@rhel70-client ~]# ipa-getcert request -k /tmp/cert/the.key -f /tmp/cert/the.crt
New signing request "20140129113309" added.
[root@rhel70-client ~]# ipa-getcert list -i 20140129113309
Number of certificates and requests being tracked: 2.
Request ID '20140129113309':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/tmp/cert/the.key'
	certificate: type=FILE,location='/tmp/cert/the.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=TESTRELM.COM
	subject: CN=rhel70-client.testrelm.com,O=TESTRELM.COM
	expires: 2016-01-30 11:33:11 UTC
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
[root@rhel70-client ~]#

Comment 8 Nalin Dahyabhai 2014-01-29 22:03:11 UTC
(In reply to Kaleem from comment #7)
> I tried with latest certmonger build and found this following message on
> console if correct selinux permission not set on directory where key or cert
> is going to be generated.
> 
> [root@rhel70-client ~]# ipa-getcert request -k /tmp/cert/the.key -f
> /tmp/cert/the.crt
> The parent of location "/tmp/cert/the.crt" must be a valid directory.
> [root@rhel70-client ~]#
> 
> I think error message here still not very clear.

Can you check if snapshots data 20140129T2030Z or later are any better?

Comment 9 Kaleem 2014-02-03 13:30:21 UTC
With build certmonger-0.70-2.el7.x86_64, still same error message.

[root@rhel70-client ~]# rpm -q certmonger
certmonger-0.70-2.el7.x86_64
[root@rhel70-client ~]# 

[root@rhel70-client ~]# mkdir /tmp/cert
[root@rhel70-client ~]# ipa-getcert request -k /tmp/cert/the.key -f /tmp/cert/the.crt
The parent of location "/tmp/cert/the.crt" must be a valid directory.
[root@rhel70-client ~]#

Comment 10 Nalin Dahyabhai 2014-02-03 14:44:41 UTC
(In reply to Kaleem from comment #9)
> With build certmonger-0.70-2.el7.x86_64, still same error message.

That is not a snapshot.  I'm running a scratch build of a current one at https://brewweb.devel.redhat.com/taskinfo?taskID=6992681

Comment 11 Nalin Dahyabhai 2014-02-18 17:02:25 UTC
(In reply to Nalin Dahyabhai from comment #10)
> I'm running a scratch build of a current one at
> https://brewweb.devel.redhat.com/taskinfo?taskID=6992681

The binaries from that build appear to have been garbage collected.  Please see
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7076174 for a rebuild.

Comment 12 Nalin Dahyabhai 2014-02-24 22:35:13 UTC
(In reply to Nalin Dahyabhai from comment #11)
> The binaries from that build appear to have been garbage collected.  Please
> see
> http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7076174 for a rebuild.

The binaries from that build appear to have been garbage collected.  Please see http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7102240 for a rebuild.

Comment 18 Kaleem 2014-12-11 11:10:29 UTC
Verified

certmonger version:
------------------
[root@dhcp207-1 ~]# rpm -q certmonger
certmonger-0.75.14-2.el7.x86_64
[root@dhcp207-1 ~]# 

snip from automation log:
========================
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: certmonger_996581 -  When getcert cannot create the key or certificate, the error should state permission denied
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [  BEGIN   ] :: Creating tmp directory :: actually running 'TmpDir=`mktemp -d`'
:: [   PASS   ] :: Creating tmp directory (Expected 0, got 0)
:: [  BEGIN   ] :: Request cert with files :: actually running 'ipa-getcert request -f /tmp/tmp.iTwfG9CpJy/test.crt -k /tmp/tmp.iTwfG9CpJy/test.key > /tmp/tmp.iTwfG9CpJy/errorfile1.txt 2>&1'
:: [   PASS   ] :: Request cert with files (Expected 1, got 1)
:: [  BEGIN   ] :: Request cert with nss db :: actually running 'ipa-getcert request -d /tmp/tmp.iTwfG9CpJy -n test > /tmp/tmp.iTwfG9CpJy/errorfile2.txt 2>&1'
:: [   PASS   ] :: Request cert with nss db (Expected 1, got 1)
:: [   PASS   ] :: File '/tmp/tmp.iTwfG9CpJy/errorfile1.txt' should contain 'could not be accessed due to insufficient permissions' 
:: [   PASS   ] :: File '/tmp/tmp.iTwfG9CpJy/errorfile2.txt' should contain 'could not be accessed due to insufficient permissions' 
:: [  BEGIN   ] :: removing /tmp/tmp.iTwfG9CpJy :: actually running 'rm -rf /tmp/tmp.iTwfG9CpJy'
:: [   PASS   ] :: removing /tmp/tmp.iTwfG9CpJy (Expected 0, got 0)

Comment 20 errata-xmlrpc 2015-03-05 10:02:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0437.html