Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 03:47:48PM -0500, Matt Zagrabelny wrote:
> On Tue, Jul 27, 2010 at 3:26 PM, Chris Baines <firstname.lastname@example.org> wrote:
> > On Wed, 2010-07-28 at 05:52 +1000, Matthew Palmer wrote:
> >> On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote:
> >> > On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines <email@example.com> wrote:
> >> > > Hello Mentors,
> >> > >
> >> > > I am looking at creating packages that involve programs that create
> >> > > caches while running of images or other files. But I am a bit stumped at
> >> > > what to do with the files they create, both where they are meant to go
> >> > > and with what permissions.
> >> >
> >> > one of these two, I would wager:
> >> >
> >> > /var/cache/
> >> > /var/lib
> >> Scratch /var/lib from that list. If the data can be recreated from another
> >> source, then it's cache data and should *not* live in /var/lib.
> >> > As for the permissions
> >> >
> >> > root:root 644
> >> If the files are created by root-owned processes, sure. It kinda smells
> >> like this is going to be done by a user-run process, which means you won't
> >> be able to apply that ownership. You will probably have to revert to
> >> per-user data stored in the homedir, unless you want to start stuffing
> >> around with suid wrappers or some such.
> > Yes, the programs are run with user level permissions. While per user
> > data would be a solution I don't want to use it just to make this
> > easier. Are there any packages that deal with these problems?
> You could create a group and then do something like:
> addgroup newpackage
> mkdir /var/cache/newpackage
> chown root:newpackage /var/cache/newpackage
> chmod 775 /var/cache/newpackage
This is only practical if the cache files are not trusted by the
application; users can directly manipulate the files and their contents. It
must be possible to verify that the cache files are correct before using
Also, if you're going to go that wild, you may as well just make the
directory group 'users' or some equally common group. Also, don't forget
the g+s and umask 002 to avoid per-user permission nightmares.
In other words: per-user caching ftw.