[Freeipa-devel] IPA service user(s)

John Dennis jdennis at redhat.com
Wed Feb 22 23:29:10 UTC 2012


On 02/22/2012 11:30 AM, Rob Crittenden wrote:
> For the most part IPA runs its services using whatever the default unix
> user is for that service, e.g. Apache as httpd, ntpd as ntp, etc.
>
> 389-ds doesn't have a system user. We create one named dirsrv in
> ipa-server-install and use that. We also remove this user when uninstalling.
>
> This can leave orphaned files, particularly log files.
>
> We've seen a few problems when upgrading to 2.2 due to this. 2.2 adds a
> memcached and a new unix user, memcache. If you've installed IPA,
> uninstalled IPA, then install a new package that adds a user (like
> memcache) then it will get the dirsrv uid and things go down hill from
> there. Your slapd logs, lock, and run dirs will be owned by memcache and
> installation will fail very early.
>
> Short-term fix for this is to not delete the dirsrv user when
> uninstalling IPA.
>
> Mid-term fix for this is to make dirsrv a known unix service user.
>
> Long-term fix is, well, up for discussion. Should we create an ipa user
> and run everything as this? This might require relocating a bunch of
> configuration so we can have custom SELinux policy. It also means we
> can/could lock down SELinux differently than the default system (read
> tighter).
>
> Thoughts?

For context see my email "Session design document"

https://www.redhat.com/archives/freeipa-devel/2011-November/msg00372.html

in which I say:

"My current recommendation would be to create a ipa:ipa user and group
identity"

My feelings are remain the same. I believe there is a security advantage 
in having specific "system" users that system daemons run under. Yes, 
SELinux can play an important role with MAC (Mandatory Access Control), 
but that does not mean DAC (Discretionary Access Control) can't play a 
useful role.

I also believe each major system daemon should be running under their 
own identity for process isolation. Thus the directory server ds should 
have it's own unique id and not run under an IPA id.

So my general recommendation would be: Each major daemon should have it 
own id in case somehow it was compromised. The ipa id would be for the 
Apache instance we run because it's what executes IPA commands, it 
communicates via sockets with other processes that perform it's bidding, 
those processes (e.g. ds, kdc, etc) would have their own dedicated id. 
The ipa_memcached process presents an interesting exception because it's 
tightly cooperative with Apache (i.e. it's implementing Apache sessions) 
thus there is an advantage to run as the same identity as Apache.

So no, I don't think everything should run as an ipa user, rather where 
it makes sense each major process should be running under a system 
dedicated id, except in those limited cases where there is very tightly 
coupled interactions (e.g. where both processes need to read/write the 
same file system objects, which at the moment only applies to 
apache/memcache)

Make sense?

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list