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 very bad. 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... :^)