mediagoblin-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GMG-Devel] Fwd: Re: Media directory permissions


From: Jim Campbell
Subject: Re: [GMG-Devel] Fwd: Re: Media directory permissions
Date: Tue, 26 May 2015 00:48:41 -0500

Thanks, all,

On Thu, May 21, 2015, at 02:19 PM, Christopher Allan Webber wrote:
> Jim Campbell writes:
> 
> > Thanks, Chris.
> >
> > On Wed, May 20, 2015, at 01:47 PM, Christopher Allan Webber wrote:
> >> Jim Campbell writes:
> >> 
> >> > Thanks for confirming, Sebastian.
> >> >
> >> > On Tue, May 19, 2015, at 02:34 AM, Sebastian Hugentobler wrote:
> >> >> 
> >> >> > I talked about it with Chris today, and we decided to go with the 
> >> >> > first
> >> >> > option. I've updated the docs to create the mediagoblin system / user
> >> >> > account with 'mediagoblin:www-data' / 'mediagoblin:nginx' permissions.
> >> >> >
> >> >> > It almost works. I think I've discovered that the user_dev directory
> >> >> > does not give any permissions to group/other by default. It only gives
> >> >> > permissions to the owner, and I think that is blocking the web server
> >> >> > from accessing the media:
> >> >> >
> >> >> > drwx------.  4 mediagoblin nginx        4096 May 19 03:01 user_dev
> >> >> >
> >> >> > I understand that user_dev/crypto is important to keep private (so 
> >> >> > that
> >> >> > would be appropriate to be set as 700), but the above default 
> >> >> > permission
> >> >> > prevents access to user_dev/media (which is where all of the beautiful
> >> >> > pictures get stored).  Somehow that permission is getting set by 
> >> >> > default
> >> >> > in that manner during installation. I think that resolving that will 
> >> >> > fix
> >> >> > media issues.
> >> >> It definitely does, I am running my instance with these permissions
> >> >> (sorry for not coming forward earlier, I overlooked this thread).
> >> >> I will take a look at my ansible role to see if there's more I forgot to
> >> >> report.
> >> >
> >> > I would probably recommend permissions of 750 on the user_dev directory.
> >> >  Chris, is this something that you could look at in the code?
> >> >
> >> > Jim
> >> 
> >> I'm a-ok with 750 for user_dev for now, yep.
> >> 
> >>  - Chris
> >> 
> >> PS: Note that in the glorious future, users will never use a directory
> >> named "user_dev"... the directory was called that because in-project
> >> virtualenv/data type installs were only meant to be for development, and
> >> the naming of such was to make it clear, but since we've never gotten
> >> real distro packaging yet this is the present reality, sadly!
> >> 
> >
> > Is it possible for you to update the default permissions for that
> > directory via a code update? How do those directories and their
> > permissions get created in the first place?  I looked through the code
> > last night to try and figure that out, and it seemed as though the
> > user_dev directory gets set up via the install.sh file or . . . a
> > different file that ends in .py that I can't recall right now (Yes, I
> > realize the latter file suggestion is completely unhelpful. I'm just not
> > in front of my home PC right now).  : )
> >
> > I would prefer a code / install-based solution over a
> > documentation-based solution, though, because if a user changes the
> > value for where their media will be stored in paste_local.ini, the
> > user_dev directory might not be in the same location as someone who
> > doesn't change that value in paste_local.ini.
> >
> > Thanks, everyone! I feel like we're close on this!
> >
> > Jim
> 
> It has been a while since I looked at this, though I think the user_dev
> directory isn't created by any one part of the codebase currently.  So,
> this is tricky to explain... there are multiple things that put things
> in user_dev, eg from the config_spec.ini which sets the defaults:
> 
>   [DEFAULT]
>   data_basedir = %(here)s/user_dev
>   
>   [mediagoblin]
>   
>   # Where temporary files used in processing and etc are kept
>   workbench_path = string(default="%(data_basedir)s/media/workbench")
>   
>   # Where to store cryptographic sensible data
>   crypto_path = string(default="%(data_basedir)s/crypto")
> 
>   [storage:publicstore]
>   base_dir = string(default="%(data_basedir)s/media/public")
> 
> Trouble is:
> 
> a) nothing creates data_basedir explicitly.  All the individual things
>    that use it in the config recursively create the directories needed in
>    order to put their own data there, if they don't exist.
> 
> b) Nothing in the code outside of the config parsing even knows about
>    data_basedir, and in fact you can specify a location that doesn't use
>    data_basedir at all (or sets it to someplace other than user_dev).
>    This means that you'll have to open up mediagoblin's full config
>    parsing tooling in order to figure out where users set the
>    directories to anyhow.
> 
> Between these two, this means that you can't trust that user_dev is
> where things are stored (again, ideally in the future people won't be
> putting their stuff there for production deployments), and in order to
> find out where users put said stuff, you have to open up python and some
> of mediagoblin's infrastructure... not necessarily easy for bash
> scripts!  (That's not to mention possibly being rude to people who don't
> want their mediagoblin data to be group readable...)
> 
> I thought, maybe we could just make those directories anyway if using
> lazyserver.sh and set the permissions, but this is really a problem for
> people running production stuff, and production stuff shouldn't need
> lazyserver.  So I'm not sure if there's a good solution.
> 
> So I think it'll have to just be a docs thing for now, as much of a pain
> in the butt as that is.  Hopefully that explaination above clarifies
> *why* it's a pain in the butt though!
> 
>  - Chris

I have updated the docs with commit
b791ae973c816f2262fb7c6efa9444c75637150d.

It is a bit less-than-ideal, as the user_dev directory isn't yet created
at this step, so I'm not married to this approach. It should work for
users who follow the deployment docs, but feel free to make changes if
you have a preferred means of setting the right permissions for this
directory.

Thanks again,

Jim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]