Russell Coker wrote:
Let's get back to basics and look at the concepts rather than AVC messages.
/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation.
Huh? su (Substitute User) has been to "Change the effective userid and group id" since I first learned about it in 1978. And is being used for that purpose in the init.d/postgresql stript.
Changing su is not the right solution
Agree.
Perhaps we need to look at pam_selinux again rather than trying to change the init.d/postgresql script?
as we don't even need 1% of the functionality of su,
all we need is a way to call setregid() and setreuid() before executing the script. I'm not sure if we already have a program we can use for this purpose (sudo is not suitable). For a test I spent 30 minutes writing a program that provides all of the su functionality we need for such things, we'll have to include that program if we don't have something better (we should have something better).Maybe we need a restorecon where it creates the data directory(if not already present (a rare occurance)).
/etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after:
echo -n $"Initializing database: "
The real work part of initializing the data directory is done with "su -l postgres -c ..." just like the part that starts the server(i.e. su -l postgres -c ...)
What is it about pam_selinux that is causing the problem?
With your latest changes to postgresql.fc and a couple of allow rules,
the server starts in the correct context when booting if the pam_selinux line is commented out of pam.d/su. That would indicate to me that there is something about pam_selinux that is the problem. The error message is:
"Unable to get valid context for postgres, no valid tty"
Perhaps the problem has to do with the 'no valid tty' part?
Thanks for your help, Richard Hally
