[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] IPA service user(s)

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


For context see my email "Session design document"


in which I say:

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

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 redhat com>

Looking to carve out IT costs?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]