Re: [Cctools-cchost] chmod 777 vs 775

[Jon P. <jo...@re...>]

On Mon, 2007-04-30 at 10:38 -0700, Victor Stone wrote:
> On 4/29/07, Jon Phillips <jo...@re...> wrote:
> > Heya VS and Others, I would like for us to change ccHost so that we
> > start out with 775 rather than 777 from the get go.
> 
> the line is
>  'file-perms'          => 0777,
> 
> in ccadmin/cc-install-db.php

cool

> >
> > It is majorly insecure esp. on Unix/Linux systems to go 777 from the get
> > go because users loose control of their system and have to ask admins
> > (if they don't have root access) to change ownership and/or move around
> > files specially.
> 
> I don't understand this, I thought write access allows anyone to
> move/delete files even without being the owner?

Right it should...

(Possibly preaching to the choir in the next paras)...

The webserver is often run as a user like apache with group apache or
httpd or nobody. Thus, files and folder get written to by the user of
the apache process, thus, if a user is not part of this group and/or if
they don't have root permissions, they loose control of the files.

Thus, a hacky solution often used is to write a script to give
permissions to the user by running from the web like unlink.php,
changepermission.php or something.

Also, often php doesn't allow for chmod and/or chown to the right access
group, which is problematic, in addition to other bolt-in security from
webhosters like dreamhost.

There is also the issue of a default umask setting on a
system...ugh...which can throw off file creation from being 777 to
another system-set value.

> >
> > I've also had a few developers get burned on openclipart.org and
> > openfontlibrary.org with setting up dev. installations.
> >
> > It seems like most system like dreamhost allow the web server to write
> > with group permissions, and at least allowing this, a user/dev won't
> > have to sink into the infinite spiral of trying to get admin help from
> > hosting company...
> 
> I still remember the flood of confused/pissed new installers on this
> list and my inbox when they installed and then didn't have access to
> the content they uploaded because php user/group is not the same as
> the admin. Since we install with 777 all of that noise has completely
> and totally STOPPED cold. this is the first I've heard of devs getting
> 'burned'?
> 
> VS

Right, for most users they won't complain because it just works, but for
admins and developers on linux/unix-type systems, 777 is too great a
security risk because those who install don't pull back the reins and
are not notified.

I think actually the solution could one or both couple of ways:

1.) provide a link in the final installation screen which does chmod -R
775 on all folders that have been 777'd, and set the setting you listed
above to 775 (although, this only solves some cases)

Or

2.) Add a blanket statement (to the unix/linux section) saying that 777
is *not* *secure* and the folks are advise to change files and folders
so that not everyone on a system can do whatever they like, and then
advise them to read the wonderful documentation you created (which I
just modified) for further enlightenment.

I'm thinking #2 is best...which is simple and I'll do...

Please excuse my round discussion here, as I just sat and thought about
the entire thought process of using 777 for installation, what wordpress
does, and yes, solving the most use cases, as using 777 has done and is
the great path we had discussed and taken...

Jon

> >
> > Another thing, no distribution would allow ccHost to get packaged and
> > ship for us with the insecurity of chmod 777 as default install.
> >
> > Thoughts? And, or, should I solve with commit ;)
> >
> > Jon
> >
> >
> > --
> > Jon Phillips
> >
> > San Francisco, CA
> > USA PH 510.499.0894
> > jo...@re...
> > http://www.rejon.org
> >
> > MSN, AIM, Yahoo Chat: kidproto
> > Jabber Chat: re...@gr...
> > IRC: re...@ir...
> >
> >
-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jo...@re...
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: re...@gr...
IRC: re...@ir...