registry team mailing list archive

[Bug Watch Updater <440314@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 6 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=24265.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-10-01T14:23:03+00:00 Martin Pitt wrote:

./src/job-mkfs.c now uses mkdtemp() in /var/run/DeviceKit-disks, but
does not create this directory if it does not exist. This regressed in
commit 84743d97547388116a31f9082b8b2c9470b34572, before that it just
used /tmp/ (which is really what /tmp/ is for, after all, but I
understand that it might cause trouble with SELinux).

Often, /var/run/ is on a tmpfs nowadays, so creating it on "make
install" (as the current source does) is not sufficient.

I see several possibilities:

 - just mkdir(PACKAGE_LOCALSTATE_DIR "/run/DeviceKit-disks") before mkdtemp()
 - use mkdtemp() in /var/run directly
 - revert to /tmp/
 - Create an init script to mkdir /var/run/DeviceKit-disks (but eww, this is a hell of a lot of boot time overhead for a simple mkdir)

I'm fine with providing a patch, but I'd like to know your opinion first
before starting to patch. Under the assumption that you want to avoid
/tmp/, I'd just go with option 2, or 1 if that makes SELinux rules any
easier.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/0

------------------------------------------------------------------------
On 2009-10-02T07:57:18+00:00 Zeuthen wrote:

> Often, /var/run/ is on a tmpfs nowadays, so creating it on "make install"
> (as the current source does) is not sufficient.

First, I think a lot of other programs do this and the FHS specifically
allows for it ("Programs may have a subdirectory of /var/run; this is
encouraged for programs that use more than one run-time file.").

Second, 'make install' should use (and does, at least with rpm and deb)
DESTDIR so at least the package payload should be correct.

Third, I think if you are careful you can still have /var/run on a tmpfs
if you really want. You just need to have some logic that copies the
directories over from the real /var/run directory at boot time. You also
need some logic when you do package install/uninstalls at run-time.

Btw, won't you see the same problem with lots of other software? I can
imagine a piece of software even creating /var/run/foo that is owned by
the user foo and all of the executables for that software run as the foo
user. You can't do mkdir in any of these executables because /var/run is
not writable for foo. Then there's also extended attributes for these
directories - e.g. SELinux security contexts.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/3

------------------------------------------------------------------------
On 2009-10-05T00:43:30+00:00 Martin Pitt wrote:

$ Btw, won't you see the same problem with lots of other software?

Mixed. Some software, like cups, mkdirs/chowns itself, for others (like
dbus) we need to do the mkdir/chown in the init/upstart script. If we
need an upstart script for a daemon anyway, then the mkdir/chown is not
a biggie.

But installing an upstart job for _just_ an mkdir is quite a large
overhead; also, this is a bit tricky with d-bus activated services since
you have to ensure that the mkdir happens before d-bus startup.

The "make install" approach works here because the directory is owned by
root:root (and thus having a subdirectory isn't even strictly
necessary). It does not work any more for services which require a
system user-owned subdirectory, since you can't put the system
user/group (>= 100, < 500) IDs into the .rpm/.deb.

Anyway, I'm fine with keeping this as a local patch as well, if you
don't want/need it in Fedora/RH.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/5

------------------------------------------------------------------------
On 2009-10-05T01:31:14+00:00 Martin Pitt wrote:

Created an attachment (id=30064)
Use /tmp/ for temporary directories

So, just for the record, I used option (2) for Debian/Ubuntu. It's a
classic usage of a temporary file/dir. It's not state which needs to be
kept through the lifetime of DK-disks, so it doesn't really need to go
into /var/run/ (https://bugzilla.redhat.com/show_bug.cgi?id=491744 does
not really give a convincing reason why /var/run/ should be used).

Keeping that here for transparency, or for other distros which might
have the same problem.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/6

------------------------------------------------------------------------
On 2010-03-12T04:16:34+00:00 Martin Pitt wrote:

David, do you think the attached patch is okay? It uses /tmp/ for what
it's supposed to be used for, but I realize this might need some
feedback from your SELinux folks?

Otherwise this should probably be closed as "wontfix", and we just keep
it in the distros.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/8

------------------------------------------------------------------------
On 2010-03-12T06:38:02+00:00 Zeuthen wrote:

(In reply to comment #4)
> David, do you think the attached patch is okay? It uses /tmp/ for what it's
> supposed to be used for, but I realize this might need some feedback from your
> SELinux folks?
> 
> Otherwise this should probably be closed as "wontfix", and we just keep it in
> the distros.
> 

I still think it's better to use /var/run/udisks... and I think
something is wrong with the OS if the /var/run/udisks isn't available.
FWIW, the FHS is very very clear on this ("Programs may have a
subdirectory of /var/run; this is encouraged for programs that use more
than one run-time file.") and I doubt udisks is the only piece of
software you need to patch. I'm closing the bug as WONTFIX.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/440314/comments/9


** Changed in: gnome-desktop
   Importance: Unknown => Medium

** Bug watch added: Red Hat Bugzilla #491744
   https://bugzilla.redhat.com/show_bug.cgi?id=491744

-- 
Disk Utility claims creating a ext4 partition failed
https://bugs.launchpad.net/bugs/440314
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for gnome-desktop.