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 with password. Password for root/admin: kadmin: addprinc temp WARNING: no policy specified for temp; defaulting to no policy Enter password for principal "temp": Re-enter password for principal "temp": 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.
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.
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.
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?
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.
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.
This bug went away with FC4. Thanks!
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 Authenticating as principal joe/admin with password. Password for joe/admin: kadmin: add_principal -randkey host/server.xxxxxx.net WARNING: no policy specified for host/server.xxxxxx.net; defaulting to no policy add_principal: Insufficient access to lock database while creating "host/server.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
What AVC message are you seeing? ausearch -m avc -ts recent rpm -q selinux-policy
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