Paul Howarth <p...@city-fan.org> writes:
> Paul Wouters <p...@xelerance.com> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
