Some of my users would like to create their own databases using postgres.
AFAICT, the targeted policy won't let them do it. Couldn't they be relaxed
(perhaps with a boolean) so as to enable databases to be created and run in say
users' home dirs, some NFS mounted, some local to the server where they'd run
the database servers?
I believe the targeted policy should allow a user to do this.
The postgres application should not transition unless run as a server.
Err... It certainly doesn't allow a user to run postmaster to have the database
listening on some (non-standard) port, and this is precisely what my user
needed. I ended up suggesting them to copy the binaries to their own home dir,
such that transitions wouldn't occur and they'd be able to run the servers, but
then, should updates be released, they won't take them automatically, which is
Since stopping users from running the database server properly will just lead
them to such undesirable behavior, since they have to get their job done, why
not get the default policy to take care of that already?
Ok, I midunderstood, Could you give me a step by step example of what a user
would do to setup a personal database. (I have never used postgres before.)
initdb -D ~/mydb # to create the database in ~/mydb
postmaster -D ~/mydb # to start the server
FWIW, this works in FC4 and rawhide, but not in FC3 (as of last Friday). I
*thought* I'd tested on FC4 as well, and it failed, but since it now works,
maybe I didn't? Or maybe the recent updates fixed it?
Anyhow, I've changed the but to reflect that the problem affects FC3 only. This
lowers its priority for me, since I'm very soon rolling FC4 out on the lab.
Yes, I was looking at FC4. In FC3 unconfined_t was transitioning by default on
all targets. We have removed this in FC4. It only happens when you start
things via the initscripts. Seems to more closely match peoples expectations.
I really don't want to update FC3 any more, so I will hold off on this until I
have to update it. FC4 is nice... :^)