Paul Howarth <paul@xxxxxxxxxxxx> writes: > Paul Wouters <paul@xxxxxxxxxxxxx> wrote: >> Can't selinux pickup things without a restorecon? And what is the >> problem another (root) process screwing over a pid or lock file? >> Can't SElinux lock that down from the /var/run level? > /var/run is var_run_t in targeted policy, but hardly anything below > /var/run is - almost every subdir/file has its own context type. > Just creating a file/directory within /var/run using the initscript will > inherit the var_run_t, which in most cases is not what's needed, hence > the need for restorecon. > Having the daemon create the file/dir works better because there will > be a type transition defined in policy that results in the correct > context type being used. That comment suggests you don't even understand the reason why those subdirectories exist. It's this: the daemons do not, and should not, run with the root privileges needed to create things directly in /var/run. The point of a subdirectory is to be owned by the lower-privilege account under which the particular daemon is running. If the subdir has to be remade at runtime, that has to be done by the root-privilege initscript, because /var/run is only writable by root. I agree with Paul W that it's not obvious why selinux can't get this right for us, instead of requiring an extra easy-to-forget step in the initscripts. But on the whole I'd rather this responsibility weren't getting dropped on the initscripts at all. It works perfectly well to set up these dirs once via RPM --- why shouldn't we make the tmpfs creation process responsible for cloning the directory structure from disk? regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
