This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 167378

Summary: kadmin cannot manipulate keys or database data due to access requirements
Product: [Fedora] Fedora Reporter: Maxwell Bottiger <sleepylight>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: dwalsh, fcdanilo
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: krb5-workstation-1.4.1-5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-03 09:50:02 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Maxwell Bottiger 2005-09-01 21:22:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I followed the directions layed out in the Kerberos section of the of the RHEL 4 reference manual.  Once I reached the step where I am supposed to enter the user and host principals I found that kadmin by default cannot access the kerberos database.  Below is a transcript:

[root@ns ~]# kadmin
Authenticating as principal root/admin@xxxxxxxxxxx.NET with password.
Password for root/admin@xxxxxxxxxx.NET:
kadmin:  addprinc temp
WARNING: no policy specified for temp@Jxxxxxxxxx.NET; defaulting to no policy
Enter password for principal "temp@xxxxxxxxx.NET":
Re-enter password for principal "temp@xxxxxxxx.NET":
add_principal: Insufficient access to lock database while creating "temp@xxxxxxxxxx".


I have looked all over and found nothing on google that helps out with the insufficient access message.  I've checked my config files and I've checked my .acl file several times.

kadmin.local works just fine.  I can add princials and create keys, but there's no luck with kadmin.  I've talked with several people and since nobody has had this problem before I'm turning it in as a bug.

Version-Release number of selected component (if applicable):
krb5-server-1.4.1-5

How reproducible:
Always

Steps to Reproduce:
1.run kadmin as an administrator to the database.  You can view principals, but cannot modify them or their passwords.
2.
3.
  

Actual Results:  add_principal: Insufficient access to lock database while creating ...

Expected Results:  principal should have been added like in kadmin.local

Additional info:

I can provide copy of any config files on request.
Comment 1 Nalin Dahyabhai 2005-09-02 14:41:40 EDT
Please post your kdc.conf file -- my main question regards the location of the
KDC's database, and until I verify otherwise, whether or not the SELinux policy
is set up to allow kadmind to write there.
Comment 2 Nalin Dahyabhai 2005-09-02 15:10:40 EDT
Yep, looks like a policy problem.  Can you run
   restorecon -r -v /var/kerberos/krb5kdc /var/log/kadmind.log
then restart kadmind and try again?  It should work then.
Comment 3 Nalin Dahyabhai 2005-09-02 15:17:28 EDT
Dan, I don't think we have policy rules in place to correctly label KDC
databases when they're created by kdb5_util.  Should kdb5_util be doing the
equivalent of a restorecon on files which it creates?  Likewise, should the
logging functions which kadmind uses do that to log files?
Comment 4 Maxwell Bottiger 2005-09-03 13:43:35 EDT
Ok.  I'm glad to hear this might be a real bug and not just me.

Here is my kdc.conf file:

[sleepylight@ns ~]$ cat /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 acl_file = /var/kerberos/krb5kdc/kadm5.acl
 dict_file = /usr/share/dict/words
 admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
 v4_mode = nopreauth

[realms]
 XXXXXXXXXXX.NET = {
  master_key_type = des-cbc-crc
  supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal
des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4
des-cbc-crc:afs3
 }


Again, I've X'ed out my domain name here.  Since you mention it, I am running
SELinux with it's default security polocy.  Next I ran the command from comment #2

[root@ns ~]# restorecon -r -v /var/kerberos/krb5kdc /var/log/kadmind.log
restorecon: invalid option -- r
usage:  restorecon [-Rnv] [-e excludedir ] [-o filename ] [-f filename |
pathname... ]
[root@ns ~]# man restorecon
Formatting page, please wait...
[root@ns ~]# restorecon -R -v /var/kerberos/krb5kdc /var/log/kadmind.log
restorecon reset /var/kerberos/krb5kdc/principal context
root:object_r:krb5kdc_conf_t->system_u:object_r:krb5kdc_principal_t
restorecon reset /var/kerberos/krb5kdc/principal.kadm5.lock context
root:object_r:krb5kdc_conf_t->system_u:object_r:krb5kdc_principal_t
restorecon reset /var/kerberos/krb5kdc/principal.kadm5 context
root:object_r:krb5kdc_conf_t->system_u:object_r:krb5kdc_principal_t
restorecon reset /var/kerberos/krb5kdc/principal.ok context
root:object_r:krb5kdc_conf_t->system_u:object_r:krb5kdc_principal_t
restorecon reset /var/log/kadmind.log context
root:object_r:var_log_t->system_u:object_r:kadmind_log_t

It looks like that got it.  I can add principals to the database now and that's
really awesome!  I've been worried for a while that it was something I had done
wrong, but it seems all is well now.  Thanks for your quick fix.
Comment 5 Christian Iseli 2007-01-22 05:33:05 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 6 Maxwell Bottiger 2007-02-03 09:50:02 EST
This bug went away with FC4.  Thanks!
Comment 7 Danilo Câmara 2010-03-22 22:24:34 EDT
I'm having this bug in Fedora 12. Don't know if I should reopen or create a new bug report.

My kdc.conf is:

# cat /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 v4_mode = nopreauth
 kdc_ports = 88,750
 kdc_tcp_ports = 88

[realms]
 XXXXXX.NET = {
  #master_key_type = aes256-cts
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
 }

I've tried restorecon as suggested above but the bug still persisted:

# restorecon -R -v /var/kerberos/krb5kdc /var/log/kadmind.log
restorecon reset /var/kerberos/krb5kdc/principal.ok context unconfined_u:object_r:krb5kdc_conf_t:s0->system_u:object_r:krb5kdc_lock_t:s0

The attributes of /var/kerberos/krb5kdc files are:

# ls -laZ /var/kerberos/krb5kdc
drwxr-xr-x. root root system_u:object_r:krb5kdc_conf_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
-rw-------. root root unconfined_u:object_r:krb5kdc_conf_t:s0 .k5.FCAMARA.NET
-rw-------. root root system_u:object_r:krb5kdc_conf_t:s0 kadm5.acl
-rw-------. root root system_u:object_r:krb5kdc_conf_t:s0 kdc.conf
-rw-------. root root unconfined_u:object_r:krb5kdc_principal_t:s0 principal
-rw-------. root root unconfined_u:object_r:krb5kdc_principal_t:s0 principal.kadm5
-rw-------. root root unconfined_u:object_r:krb5kdc_principal_t:s0 principal.kadm5.lock
-rw-------. root root system_u:object_r:krb5kdc_lock_t:s0 principal.ok

I've tried to give them all system_u but it didn't solve:

# chcon -u system_u -v /var/kerberos/krb5kdc/*
changing security context of `/var/kerberos/krb5kdc/kadm5.acl'
changing security context of `/var/kerberos/krb5kdc/kdc.conf'
changing security context of `/var/kerberos/krb5kdc/principal'
changing security context of `/var/kerberos/krb5kdc/principal.kadm5'
changing security context of `/var/kerberos/krb5kdc/principal.kadm5.lock'
changing security context of `/var/kerberos/krb5kdc/principal.ok'

Whenever I try to add a principal I got the error:

# kadmin -p joe/admin@XXXXXX.NET
Authenticating as principal joe/admin@XXXXXX.NET with password.
Password for joe/admin@XXXXXX.NET: 
kadmin:  add_principal -randkey host/server.xxxxxx.net
WARNING: no policy specified for host/server.xxxxxx.net@XXXXXX.NET; defaulting to no policy
add_principal: Insufficient access to lock database while creating "host/server.xxxxxx.net@XXXXXX.NET".

Searching the web I found something similar in http://nfsv4.bullopensource.org/doc/kerberosnfs/krbnfs_howto_v3.pdf and discovered that running /usr/kerberos/sbin/kadmind directly, instead of using "service kadmin start", I was able to create the principals.

RPMS I'm using:

# rpm -qa|grep krb5
krb5-libs-1.7.1-2.fc12.i686
krb5-libs-1.7.1-2.fc12.x86_64
pam_krb5-2.3.7-2.fc12.x86_64
krb5-auth-dialog-0.13-2.fc12.x86_64
krb5-workstation-1.7.1-2.fc12.x86_64
krb5-devel-1.7.1-2.fc12.x86_64
krb5-server-1.7.1-2.fc12.x86_64
Comment 8 Daniel Walsh 2010-03-23 08:04:25 EDT
What AVC message are you seeing?

ausearch -m avc -ts recent

rpm -q selinux-policy
Comment 9 Danilo Câmara 2010-03-23 10:22:31 EDT
Today after a reboot the problem was gone.

Now changing the context of "/var/kerberos/krb5kdc/principal.ok", I see restorecon solves the problem immediately. I don't know why it didn't work yesterday. I apologize.

For the record:
# ausearch -m avc -ts recent
<no matches>

# rpm -q selinux-policy
selinux-policy-3.6.32-103.fc12.noarch