Bug 244941 - /var/run is not cleaned up properly
Summary: /var/run is not cleaned up properly
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-19 23:36 UTC by David Zeuthen
Modified: 2014-03-17 03:07 UTC (History)
3 users (show)

Fixed In Version: 8.70-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-15 17:06:13 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.