chmod madness, enlightened advice welcome

Destry · 2016-06-27 13:10:31

This is a chmod question in general regarding my local dev.

I have a system installed in my /Sites web root, and I can change permissions easily enough on most directories in the location. For these directories, I can run something like this to see what permissions exist on the child elements…

ls -l storage
drwxrwxr-x    4 destry  staff   136 Jun 20 08:42 cache
drwxrwxr-x    3 destry  staff   102 Apr 21 16:22 formatter
drwxrwxr-x  138 destry  staff  4692 Jun 17 14:34 less
drwxrwxr-x    2 destry  staff    68 Mar 28 07:04 logs
drwxrwxr-x    5 destry  staff   170 Apr 21 21:41 tmp
drwxrwxr-x    9 destry  staff   306 Apr 22 18:02 views

Which is showing 775 for all those directories, and “destry” as the owner and “staff” as the group (I think that’s what that means).

But in that one /less directory, it’s full of items like this…

-rwxr-xr-x  1 _www    staff    17063 Jun 12 11:46 lessphp_14kjn4fqnjb48w8w0c0wo0cc0cos40g.lesscache
-rwxr-xr-x  1 _www    staff    26636 Jun 12 11:46 lessphp_18x2bkuuqin4kkgso88sw480wog88c4.lesscache
-rwxr-xr-x  1 _www    staff    75692 Jun 10 17:56 lessphp_1bef9xp6mh6sccc8844kgo0sggkgkg0.lesscache
-rwxr-xr-x  1 _www    staff    16777 Jun 12 11:46 lessphp_1sot8ushvptwc0ww444s8wg88c8wwc0.lesscache

Where _www is now the owner.

I’ve tried running…

chmod -R 0775 less

But it doesn’t change permissions on the contained files. And if I try changing permissions on a single file (which would take a monotonous two full days to get them all one by one anyway), I get this…

chmod: Unable to change file mode on {file}: Operation not permitted

The permissions on these files are crashing my webapp, they need changed to 775 (or even 777), but I can’t seem to change them. I suspect it’s because of that _www owner value.

This issue all came about when I updated to php 7.0.7 and mysql 5.7.13, though I’m guessing it was the php update that changed things.

Where does _www come from and how can I change myself to owner so I can change permissions on the files?

gomedia · 2016-06-27 14:08:50

_www is the user that runs Apache.

To change permissions try:

sudo chmod -R a+w less

Bloke · 2016-06-27 14:33:57

If you don’t need that directory to have _www as owner you could change it to yourself:

sudo chown -R destry less

That might result in your site requiring lighter permissions on that directory. Or it might break stuff and you’ll have to change it back:

sudo chown -R _www less

:-) But it might be worth a shot anyway.

Destry · 2016-06-27 15:57:27

Thanks, guys. Both of your suggestions function as intended. I now have, for example…

-rwxrwxr-x  1 destry  staff    17063 Jun 12 11:46 lessphp_14kjn4fqnjb48w8w0c0wo0cc0cos40g.lesscache
-rwxrwxr-x  1 destry  staff    26636 Jun 12 11:46 lessphp_18x2bkuuqin4kkgso88sw480wog88c4.lesscache
-rwxrwxr-x  1 destry  staff    75692 Jun 10 17:56 lessphp_1bef9xp6mh6sccc8844kgo0sggkgkg0.lesscache
-rwxrwxr-x  1 destry  staff    16777 Jun 12 11:46 lessphp_1sot8ushvptwc0ww444s8wg88c8wwc0.lesscache

But I still get this error on the front-end with nothing displaying…

Less_Exception_Parser
Less.php cache directory isn't writable: /Users/destry/Sites/discussion/storage/less/

Which of course isn’t true…

drwxrwxr-x  138 destry  staff  4692 Jun 17 14:34 less

I do not know.

In any case, you answered by questions. Thank you. Time to take this to the vendor’s camp, I guess.

Destry · 2016-06-28 16:17:10

How would I figure out what ‘user’ and ‘group’ my web server is running with? Based on the previous post above, are those values definitively “destry” and “staff”?

I’m being told I need to get the ‘user’ and ‘group’ in the www.conf file set to www-data, for example:

user = www-data
group = www-data
...
listen.owner = www-data
listen.group = www-data

But if my server user and group are destry/staff, then those www.conf values should be destry and staff, respectively, right?

EDIT: Okay, this will find what users are running on the server, apparently:

ps aux | egrep '(apache|httpd)'

Which says on my Mac server I have: destry, _www, and root.

Based on some responses here, “www-data” is a default user on Ubuntu. So that wouldn’t even apply to me.

“destry” looks like the golden egg for user on my local, though “_www” should work too, theoretically.

But what about finding the group? I’m guessing it’s “staff” on Mac.

I’ll go try a couple things…

Last edited by Destry (2016-06-28 16:29:33)

Destry · 2016-06-28 16:57:06

Interesting, so in my …/apache2/httpd.conf file I have this set:

<IfModule unixd_module>
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.  
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User _www
Group _www

</IfModule>

which would explain the _www I was seeing earlier. I guess I don’t know where the “staff” group is coming from, then.

I’ll try changing the group in the uncooperative directory to “_www” and see what monkeys fly south.

Destry · 2016-06-28 17:00:24

Btw, it helps me to think aloud. ;)

Bloke · 2016-06-28 22:34:56

Destry wrote #300023:

which would explain the _www I was seeing earlier. I guess I don’t know where the “staff” group is coming from, then.

Chances are your OSX user name is destry and you’re in the staff group. Issue the command: id and it’ll tell you the uid (user id) and gid (group id) of your user account. Thus, every file you create will assume those roles. So when you copied over Txp files to your installation directory, that’s what you get.

Then along comes apache. It serves each page as the _www user and _www group, because it says so in the httpd.conf (or www.conf, or whatever .conf file your chosen LAMP stack uses). When it looks at your directory where you copied Txp’s files, it sees them owned by destry : staff and complains because it can’t access them. The only way to open it up without changing owner/group membership of the files is to enable “other”, i.e. world-read-write-execute. You probably don’t want to do that in a live environment, but on localhost for testing, it’s probably fine.

Assuming you’re averse to world-writable files (I am) now comes the dilemma. You want to be able to copy files in as “yourself” (destry/staff) but you also want the web server to be able to read and write content as “apache” (_www/_www). The easiest thing I find is to simply add yourself to the _www group. That way, you can still write your files to the folder as long as group permissions are set to “w”. Uhh, usually. Although I’ve had issues where some things required user permissions for reasons I have yet to fathom. But let’s sidestep that and hope it works out okay in this case.

Now, in Linux, adding yourself to a group is a simple one-liner: useradd -G _www destry. Done. OSX, however, uses more complex ACLs (access control lists) to manage permissions, and things got a whole lot tighter in El Capitan with its rootless access and protected System areas. tl/dr: you can use the GUI if you want to wade through System Prefs/User Accounts, or use the dscl command. I’ve never used it, but there’s some help available if you can decipher it.

Hope some of that helps and doesn’t cloud the atmosphere further.

gomedia · 2016-06-28 23:07:26

On my Mac I’ve never had to muck around with groups in http.conf, so here’re some general points that apply in my setup.

The user/group _www / staff is quite normal on files created by PHP etc.

On files/images that have been uploaded it’s _www / wheel. So in the images folder, the image files are group “wheel” and the thumbnails are group “staff”.

All I need to do on directories that are under my Sites directory (which are adi / staff) to give PHP (& hence TXP) write access is to set the “others” permissions.

For example the images folder starts off being drwxr-xr-x, and to give TXP write access to it:

chmod o+w images

so it ends up being drwxr-xrwx.

Destry · 2016-06-29 09:48:47

You guys are wonderful. Patiently helping me learn. And it is a help, and I am learning a lot more than I knew 5 days ago about permissions on my system and lovely new command-line tricks.

My local Txp installs are actually working fine. This has to do with my one instance of Flarum (thus a ‘general’ discussion here).

I’ve managed to fix the problem, but I had to use chmod -R 777 on the entire install directory to get it to work. Also the user on the /less directory files had to be changed from ‘_www’ to ‘destry’ (the group ‘staff’ was okay, apparently). And the so-called “www.conf” file that the Flarum crowd had me chasing had nothing to do with anything. Some more on that part…

My trouble happened when updating php5 to 7.0.7 via the L//P package, which, btw, doesn’t overwrite the Mac’s native php binaries but installs 7 alongside and does a couple of simple overrides in the .ini file, for example. This way when someone updates their OS to Sierra later, which will have it’s own native (and newer) version of php7, presumably, it will overwrite the native binaries and the L//P package can be removed without issue.

Anyway, after updating to php7, I was getting an orange-table error on the front-side, this one in particular

That’s when the (misguided) suggestions about editing the “www.conf” file came up. I couldn’t find this file at first because it was located and named differently in my Mac, at /user/local/php{n}/etc/php-fpm.d/www.conf.default I’m assuming the .default extension means it was not even active, and yet my Txp sites were working just fine. The lines they wanted me to change in that file were the ones I mentioned here, which in my files were set as nobody for both user and group, which I’ve learned on Stack Overflow is a default setting for certain OS packages, like mine, obviously.

After a lot of pointless fiddling with www.conf.default file (dropping the .default extension and changing user/group values) in both the php5 and php7 installs (because I wasn’t sure if one or the other was the “live” one), I realized that any change to either file location resulted in a change to the same file. I’m not sure how that magic works, but I’m guessing there’s symbolic linking there, or whatever. In any case, whatever I tried had no affect on the error problems. So I put the user and group values back to “nobody” and added .default back on the file name and backed out of the crypt slowly, leaving the room like I found it to not piss of Ra. I’m convinced the www.conf.default file has nothing to do with the issue because every thing is working fine now without it.

That is if you consider chmod 777 on an entire install directory fine. But no matter what combination of things I tried, I could not get it to work any other way. I know Ruud is always advocating 775, and for good reason, but I’ve never been able to get 775 to work.

Anyway, when I changed my user from ‘www’ to ‘destry’ on the _/less directory and files, that made the original “Failed to open stream: Permission denied…” errors go away, replacing it with Flarum’s own “Whoops” error console with a new error showing:

Less_Exception_Parser
Less.php cache directory isn't writable: /Users/destry/Sites/discussion/storage/less/

This was actually a step in the right direction, because if you see errors in Flarum, that console is where they’re supposed to show up.

At that point I tried running 775 on the entire install directory (~/Sites/discussion), and then tried 775, 755, and finally 777 on the /less directory alone where the error says there’s a problem — restarting Apache every time — but the same “Less_Exception_Parser” error remained. Only when doing 777 on the entire install directory did it finally bring the site back.

I haven’t tried any of the things you suggest most recently, Steph, about adding ‘destry’ to the ‘_www’ group, but I might try that later. Need to run for a while.

Thanks again. I love the learning in pursuit of solutions even when the solutions evade. ;)

gomedia · 2016-06-29 11:12:58

Only when doing 777 on the entire install directory did it finally bring the site back.

Sometimes, when tweezers don’t work … you have to use a hammer

Bloke · 2016-06-29 11:14:46

Glad to be able to (sort of) help. As I mentioned, on a local installation the setup you’ve chosen will be fine, but assuming you’ll eventually be migrating the whole caboodle to a live site somewhere in web land, it’s helpful to familiarise yourself now with the issues you might face at that time. 777 is a band-aid to cover up poor permissions setups, not a robust solution! (though feel free to hammer away, as Adi says, on local sites).

In your case:

the web server (apache) needs read access to everything.
apache needs additional write access to the less directory. Possibly others, but let’s start there; the process can be copied out to other directories that require write access on a case-by-case basis.
on the staging site you need to be able to copy files into the webroot area.
on the live site you need to be able to upload (FTP) files to the webroot area.

In theory — and this is only theory as I’ve rarely managed to get it to work to my satisfaction — you can have fewer permissions for the owner than you do for the group, and this should satisfy apache. It looks a bit weird, but the best setup is to have permissions set to 570 for writable locations:

r-x for the file/directory owner.
rwx for the group.
--- (nothing) for anyone else.

and 550 for anything else.That’s total lockdown, only allowing key personnel to do the absolute minimum they require. If your files are all owned by whatever group that apache runs as (_www in your case), and that group has rwx (7) permissions it should be able to write to that directory. If your user account (destry) is also a member of _www then it’s happy days, as you can write too. Then it doesn’t matter who owns the files as long as the group is given full permissions.

However, a lot depends on two main factors:

How your host has set up the hosting/apache environment (which depends on settings for umask, setgid, httpd.conf, php.ini, fastcgi, suExec, and so forth).
The permissions and ownership of the containing directory in the tree (/Users/destry/Sites for your staging site, probably /var/www/domain-name for the live site, assuming some Linux derivative.

In order to allow yourself to be able to overwrite/FTP, you usually end up having to modify the ideal by setting 750 for the entire site:

rwxr-x---   destry   _www   file_or_directory_name

and 770 for any specific folders that require write access by apache:

rwxrwx---   destry   _www   file_or_directory_name

However, in some instances, apache won’t run properly if it doesn’t also have ownership. In that case you have to set the owner explicitly to appease apache:

rwxr-x---   _www   _www   file_or_directory_name

for most files/directories and:

rwxrwx---   _www   _www   file_or_directory_name

for locations that require write access. If you’ve set your user account to be a member of the _www group and lady luck is shining, you may even be allowed to alter/overwrite/FTP the files. But depending on how things are set up, you may be denied. In that case you are faced with either:

a) allowing 777 permissions on other. Don’t do this on live sites!

b) using sudo before all commands to run them with elevated privs, and then doing:

sudo chown -R _www:_www file-or-directory-you-just-changed
sudo chmod -R 770 file-or-directory-you-just-changed

The latter doesn’t fix any FTP problems you may encounter though, as you probably won’t be able to FTP into the webroot directly either. In this (worst) case you’re lumbered with setting up an area on the live site — maybe in your home directory — that is owned by your FTP user into which you can upload files. Then you hop onto the server via SSH, copy the files into webroot and do the chown/chmod dance via the command line, with all of those commands using sudo. Bit of a ballache, but way more secure than 777.

Phew!

Last edited by Bloke (2016-06-29 11:16:57)

Textpattern CMS

Textpattern CMS support forum

#1 2016-06-27 13:10:31

chmod madness, enlightened advice welcome

#2 2016-06-27 14:08:50

Re: chmod madness, enlightened advice welcome

#3 2016-06-27 14:33:57

Re: chmod madness, enlightened advice welcome

#4 2016-06-27 15:57:27

Re: chmod madness, enlightened advice welcome

#5 2016-06-28 16:17:10

Re: chmod madness, enlightened advice welcome

#6 2016-06-28 16:57:06

Re: chmod madness, enlightened advice welcome

#7 2016-06-28 17:00:24

Re: chmod madness, enlightened advice welcome

#8 2016-06-28 22:34:56

Re: chmod madness, enlightened advice welcome

Destry wrote #300023:

#9 2016-06-28 23:07:26

Re: chmod madness, enlightened advice welcome

#10 2016-06-29 09:48:47

Re: chmod madness, enlightened advice welcome

#11 2016-06-29 11:12:58

Re: chmod madness, enlightened advice welcome

#12 2016-06-29 11:14:46

Re: chmod madness, enlightened advice welcome

Board footer