Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156452 - RFE: skel.tmp - folder for storing /tmp skeleton
Summary: RFE: skel.tmp - folder for storing /tmp skeleton
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Mike McLean
Depends On:
Blocks: 155800
TreeView+ depends on / blocked
Reported: 2005-04-30 15:31 UTC by Ivan Gyurdiev
Modified: 2014-03-17 02:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2005-05-09 08:11:25 UTC

Attachments (Terms of Use)

Description Ivan Gyurdiev 2005-04-30 15:31:07 UTC
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):

How reproducible:
Didn't try

Additional info:

Comment 1 Bill Nottingham 2005-05-02 16:15:42 UTC
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.

Comment 2 Ivan Gyurdiev 2005-05-02 18:41:37 UTC
> 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:


Comment 3 Bill Nottingham 2005-05-02 18:58:37 UTC
This screams out to me `put it in ~/tmp'. :)

Comment 4 Ivan Gyurdiev 2005-05-02 19:03:26 UTC
So why isn't it done that way?

Comment 5 Bill Nottingham 2005-05-02 19:12:07 UTC
Probably concerns about sockets-over-nfs, or something similar.

Comment 6 Ivan Gyurdiev 2005-05-02 19:17:22 UTC
Will you consider the skel proposal then?

Comment 7 Ivan Gyurdiev 2005-05-02 19:35:49 UTC
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.

Comment 8 Ivan Gyurdiev 2005-05-09 08:11:25 UTC
Ok I've implemented a patch for orbit, and I'm now thinking a 
tmp skel is the wrong way to go - closing bug.

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