Bug 156452 - RFE: skel.tmp - folder for storing /tmp skeleton
RFE: skel.tmp - folder for storing /tmp skeleton
Product: Fedora
Classification: Fedora
Component: filesystem (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Mike McLean
: FutureFeature
Depends On:
Blocks: 155800
  Show dependency treegraph
Reported: 2005-04-30 11:31 EDT by Ivan Gyurdiev
Modified: 2014-03-16 22:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-09 04:11:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-04-30 11:31:07 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):

How reproducible:
Didn't try

Additional info:
Comment 1 Bill Nottingham 2005-05-02 12:15:42 EDT
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 14:41:37 EDT
> 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 14:58:37 EDT
This screams out to me `put it in ~/tmp'. :)
Comment 4 Ivan Gyurdiev 2005-05-02 15:03:26 EDT
So why isn't it done that way?
Comment 5 Bill Nottingham 2005-05-02 15:12:07 EDT
Probably concerns about sockets-over-nfs, or something similar.
Comment 6 Ivan Gyurdiev 2005-05-02 15:17:22 EDT
Will you consider the skel proposal then?

Comment 7 Ivan Gyurdiev 2005-05-02 15:35:49 EDT
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 04:11:25 EDT
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.