Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 30, 2010, at 4:01 PM, Tom Lane wrote:

> 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 was nodding my head in agreement reading this paragraph, and then I
looked at my development box. Only avahi-daemon and hald follow this
pattern in my /var/run (which I'm sure is not a complete sample).

joe


-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux