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).
/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: "
Maybe we need a restorecon where it
creates the data directory(if not
already present (a rare occurance)).
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