Red Hat Bugzilla – Bug 156452
RFE: skel.tmp - folder for storing /tmp skeleton
Last modified: 2014-03-16 22:53:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3
Description of problem:
I would like to request the inclusion of a new folder called skel.tmp in /etc. My idea is that the folder would be used to re-create a skeleton for /tmp folders by a startup script on every boot.
Such a skeleton is needed, because certain folders in /tmp require a persistent security context, regardless of which application creates the folder - the easiest way to accomplish that, is to have the folder be created by a central script during startup. I say "re-create" and not "create", because the user should be able to place /tmp on tmpfs.
For example, I am suggesting that the gconf package includes a folder called /etc/skel.tmp/gconfd-USER, or something like it. A startup script can then scan this folder, and create the appropriate folder in /tmp, replacing USER with each individual user. After creating the folder (or if it already exists), the script would call restorecon on it to set the appropriate security context.
Version-Release number of selected component (if applicable):
I don't see why this would be needed; the startup script can just create the
necessary directories without this.
Alternatively, gconfd could actually set the context correctly itself.
> I don't see why this would be needed; the startup script can just create the
> necessary directories without this.
That's true, but that's an ugly way to do it, IMHO, because:
1) You'd have to check what apps are installed, or create all folders by default.
2) Third party applications can't just add a folder to skeleton, they have
to modify the script..
> Alternatively, gconfd could actually set the context correctly itself.
How would you fix the Sun java vm, for example, which is not open source?
It stores things in /tmp/hsperfdata_$USER, which needs fixed per/user
context, independent of the creating app. Adding a skel folder is
something the package maintainer can do, while modifying the app may
not always be possible.
In addition, there's multiple applications to change, not just gconf:
This screams out to me `put it in ~/tmp'. :)
So why isn't it done that way?
Probably concerns about sockets-over-nfs, or something similar.
Will you consider the skel proposal then?
Well, okay...I guess gconfd can be handled by file_type_auto_trans()
I guess Java can be handled by a startup script as "the exception".
I'm not sure about scrollkeeper...
Orbit definitely requires changing the code to call restorecon.
Ok I've implemented a patch for orbit, and I'm now thinking a
tmp skel is the wrong way to go - closing bug.