Bug 162769
Summary: | users can't create/use postgres databases | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | Keywords: | FutureFeature |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-07-20 03:47:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alexandre Oliva
2005-07-08 15:23:10 UTC
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... :^) |