kadmin.local works but kadmin doesn't. kpasswd 'insufficient access to lock data base'

[Jeffrey Hutzelman]

On Tuesday, June 13, 2006 03:00:20 AM -0400 Ken Raeburn <raeburn at mit.edu> 
wrote:

> On Jun 12, 2006, at 16:03, bohongdxl at gmail.com wrote:
>> The whole problem is solved. Man page for 'kerberos_selinux'
>> essentailly says that selinux protection for krb5kdc and kadmind needs
>> to be turned off using the following commands:
>
> How odd.  I don't know anything about selinux, but I find it pretty
> strange that it wouldn't let you run two services that need to share
> a database in read-write mode...

It's not operating at that level.  SELinux applies additional constraints 
on what a process can do based on the context of that process, policy 
configuration, and the labels on files the process is trying to access.  As 
far as I can tell, process context is determined by a combination of 
inheritance and the security labels on executed files.

Fedora Core systems ship with two possible policy databases, which they 
call "strict" and "targeted".  The "strict" policy is a "default-closed" 
policy; only actions explicitly permitted by policy are permitted.  The 
"targeted" policy, which is the default, only applies restrictions to 
particular programs and daemons which are considered particularly risky. 
Mostly, this means things that provide network services (like kadmind) or 
run with more privileges than the user who invoked them (like su).

The OP's description indicates that when he runs kadmind by hand, it runs 
in the context 'unconfined_t', which should only happen in the 'targeted' 
policy (I'm not sure that type even exists in 'strict').  So, I'm going to 
assume that's the policy he's using.  In FC5, the 'targeted' policy allows 
kadmind write access to /var/kerberos/krb5kdc/principal.*, but not to any 
other files in that directory.

Setting the boolean 'kadmind_disable_trans' disables the transition into 
'kadmind_t' when kadmind is run by the init script.  So, it stays in 
whatever less-restrictive context the init script was running in, and can 
write to whatever file it's having problems with.



I'd suggest looking at the kadmind log and/or attaching strace to the 
running strace to see what file it's trying to access that is prohibited by 
policy.  Then adjust the policy to correct the problem.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA