Logining into www-data

[bab1]

Drupal's check for "can I write" consists of an "if i_am_owner && is_owner_writable" of which it runs as www-data, thanks to Apache being the calling process.

Have you see this code yourself? Can you direct me to this code.

I meant modification, not removal. My bad on that, but Drupal creates/downloads/extracts as 755 for directories and 644 for files. Thus, if the user is not www-data it cannot modify auto-installed files & directories.

The default umask (002) supplied permissions are 775 = directory and 664 = files. In the reading I have done I don't see where Drupal alters that. I'm sure the repo version of Drupal works like that. Have you altered the configuration specifications?

That's why I said "I don't see" rather than "there isn't". I can guarantee there is a way, it's just not obvious to me.

No, there isn't. If the one in the repo is like some of the other web scripts, then I could snag it from the repo and there would be. And even if there was, I would be having the same discussion, but with the the Drupal user rather than the www-data user. I would rather not go through the pain of making Apache run as multiple users and even if I did, how would I set Apache to use a password protected user?

You seem fixated on "the drupal user" I never said you should use a drupal (system) user. Maybe you are confused with the notion of a mortal user of Drupal.

Hmm... Would it be able to preserve group write?

The permissions are not set by sgid. They are set by the last use of umask. As I said the default umask is 002 which already has group rw, but there is no reason why a script can't reset the umask to 022 (755/664). If Drupal has a script that resets the umask you can always set it back or install the repo version which has already worked out these problems.

What is the umask on the machine you are using? Post the output of

umask

What version of Ubuntu are you using? Post the output of this

lsb_release -a

Edit: It appears you can set the Drupal umask settings with this file: sites/default/settings.php What does it say in there?

[TheFu]

Set Group ID - setguid - commonly known as the "group sticky bit" is a basic UNIX file system permission. I showed the octal setting, but most of hte time it is seen as chmod g+s.
To learn about it, nothing will replace making a few users, putting them into a few different and same groups and playing around with the user and group permissions for an hour to see the subtle permission changes possible. It has been this way for 40 yrs and needs to be well understood by system admins and anyone who deploys a web-app that is internet facing.

I only posted for sudo and chmod knowledge. Cannot pretend to understand what is in the mind of any other person or F/LOSS project team.

umask is userid specific. It is common to override in the ~/.profile or ~/.bashrc.

[wolfgentleman]

Have you see this code yourself? Can you direct me to this code.

I have not poked through the code, but by process of elimination the it can only be satisfied by being the owner.

The default umask (002) supplied permissions are 775 = directory and 664 = files. In the reading I have done I don't see where Drupal alters that. I'm sure the repo version of Drupal works like that. Have you altered the configuration specifications?

IDK, but when I use the auto-install it is set as a owner-only write.

You seem fixated on "the drupal user" I never said you should use a drupal (system) user. Maybe you are confused with the notion of a mortal user of Drupal.

Ah. So you were referring to making the user that uses Drupal to have Apache run as them for their directory?

What version of Ubuntu are you using? Post the output of this

lsb_release -a

No LSB modules are available.Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

Edit: It appears you can set the Drupal umask settings with this file: sites/default/settings.php What does it say in there?

I can't find it with a search. I'll look for it further when I'm in a better mood. I feel like all I've been doing is arguing about or fixing something today.

[SeijiSensei]

Having just migrated a Drupal site, I'll toss in my two cents.

I created a user to own the Drupal tree, let's call it "drupal". I unpacked the Drupal tar.gz file in that directory and created a symlink called "current" pointing to that directory. As the drupal user I ran:

$ cd /home/drupal
$ ln -s drupal-7.37 current

I then added the Apache user, "www-data" on Ubuntu, to the "drupal" group in /etc/group.

Finally I made the entire /home/drupal/drupal-7.37 tree read-only to user and group with no permissions for other. I added group-writable privileges to drupal-7.37/sites/default/files, where user file uploads like graphics are stored.

You'll also need to create a couple of group-writable directories to handle module updates.

See these documents:
https://www.drupal.org/node/244924
http://drupal.stackexchange.com/ques...rary-directory

The webserver uses /home/drupal/current as its DocumentRoot for the site.

[wolfgentleman]

I had a thought that may satiate y'all's problem with the system "vulnerability" that loggin in with www-data created. Even though I don't see how it is insecure in any form.
Requirements:

1. 2 users per site:
   
   1. User 1
      
      1. Password: Yes
      2. SSH Login: Enabled
      3. Shell: Script that su's into User 2
      
      
   2. User 2
      
      1. Password: No
      2. SSH Login: Disabled
      3. Shell: /bin/bash
   
   
2. Apache MPM setup like this tutorial

But then again, this is basically what I am currently doing, except each user is isolated to their own directory. Just some thoughts.

[TheFu]

If you are using passwords for remote connectivity, then you have already failed on the security-side.
I don't see why a 2nd user is desired, but I haven't been following this very closely.

[wolfgentleman]

If you are using passwords for remote connectivity, then you have already failed on the security-side.

Yeah, I have been meaning to move to SSH keys instead. So consider the "password" either a password or an SSH key.

I don't see why a 2nd user is desired, but I haven't been following this very closely.

So it can be used by Apache's MPM module. It may not be required, I didn't look very deep into making Apache run as multiple users.

[TheFu]

I'd probably just use LXC if I wanted apache compartmentalized beyond what AppArmor can do.

[wolfgentleman]

I'd probably just use LXC if I wanted apache compartmentalized beyond what AppArmor can do.

I had to look both of those up...

1. I found the Ubuntu page on AppArmor, but I couldn't get the gist of what it was by skimming. I'll read more later when I'm not so busy.
2. Correct me if I my Google Foo failed me, but LXC is like a CPanel?

[SeijiSensei]

You'll also need to create a couple of group-writable directories to handle module updates.

Well, Drupal seems even more complicated than I first imagined.

When you update modules in Drupal, you have to have a working account with an FTP or SSH login. So that means the "drupal" user I discussed above needs a password. That user also needs to own sites/all/modules and have write privileges there.

I'm guessing all this complexity is required to work in hosted environments, but if you control the whole server like I do, it's a royal pain in the ....