Bug 244941

Summary: /var/run is not cleaned up properly
Product: [Fedora] Fedora Reporter: David Zeuthen <davidz>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: mclasen, rvokal, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: 8.70-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-15 17:06:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Zeuthen 2007-06-19 23:36:20 UTC
Reading

 http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA

it says that if I have a package Foobar2000, I can create a directory

 /var/run/Foobar2000

to use for run-time variable data and I can rely on this being cleaned up on
reboots. It works fine - if I drop file like

 /var/run/Foobar2000/some-random-file

and it's gone on the next reboot - however if I do

 /var/run/Foobar2000/some-directory/some-random-file

it sticks around. 

This is actually a potential security risk depending on how /var/run is used
(see below).

Am unsure about the wording of FHS (it's vague) but am pretty sure this is
wrong. The reason I want this is for PolicyKit - I'd like to store temporarily
granted privileges in a per-uid sub directory, e.g. like this (note the permissions)

# tree -ugp /var/run/PolicyKit
/var/run/PolicyKit
`-- [drwxrwx--- davidz   polkit  ]  uid500
    |-- [-r--rw---- davidz   polkit  ] 
pid-4820@84518-polkit-gnome-examples-frobnicate.grant
    |-- [-r--rw---- davidz   polkit  ] 
pid-4820@84518-polkit-gnome-examples-tweak.grant
    |-- [-r--rw---- davidz   polkit  ] 
pid-4827@86436-polkit-gnome-examples-frobnicate.grant
    |-- [-r--rw---- davidz   polkit  ] 
session-Session1-polkit-gnome-examples-punch.grant
    `-- [-r--rw---- davidz   polkit  ] 
session-Session1-polkit-gnome-examples-twiddle.grant

e.g. where only uid 500 can see what privileges uid 500 have been granted.

<offtopic>
To explain the potential (minor) security problem the existence of the file 

/var/run/PolicyKit/uid500/pid-4827@86436-polkit-gnome-examples-frobnicate.grant

means that the process with pid 4827, created 864.36 seconds after the kernel
booted, and owned by uid 500 is privileged for invoking actions on mechnanisms
(D-Bus system daemons or setuid helpers) that require the
'polkit-gnome-examples-frobnicate' privilege. If this is not cleaned up on
reboot.. there's a slight chance that uid 500 can create a process with pid 4827
and age 864.36 seconds on the next reboot...
</offtopic>

Anyway, I think this is an easy fix to be a bit more FHS compliant.

Comment 1 Bill Nottingham 2007-06-20 03:41:37 UTC
Yeah, the problem is reimplementing find.

Comment 2 David Zeuthen 2007-06-20 15:42:55 UTC
(In reply to comment #1)
> Yeah, the problem is reimplementing find.

I'm curious if you agree that we're violating the FHS by not cleaning up these
files.

Comment 3 Bill Nottingham 2007-06-20 15:46:52 UTC
From a quick reading, we are. Of course, it's sort of unclear as to whether, in
your example, the uid500 directory should be removed or not.

Comment 4 Bug Zapper 2008-04-04 12:50:10 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.