Hey,

Is there any indepth read pertaining to users and groups?

For instance.

My wordpress wouldn't update because the owner of the files was the ftp user. So the directories were all user1:apache.

Now because the group was apache, i would have already assumed that apache could upgrade wordpress automatically but it didn't. I had to chown the files to apache:apache in order for it work.

So my question is, should i be adding my user to the apache group or leaving it as apache:apache. I'm just worried about security of the site.

Thanks and sorry if it didn't make sense. I'm learning. lol (Yes I did search)

Have you tried searching the Wordpress site:

https://wordpress.org/support/topic/...user-and-group

http://codex.wordpress.org/Hardening_WordPress

thanks I'll look into those links


Question though, if I set a chown user1:group2 on a file. Is the owner of the file user1 from group2 or user1 and everybody from Group2, and if it's just user1, what if he is not part of group2 but permissions says that he is?

Not a possible situation.

If the user is not part of the group, then group permissions will not work. That would require the "other" permissions, or an ACL applied to the file.

So if my files were set to user1:Apache and the user is not part of Apache, the group would not have any permissions? Sorry I'm learning, I'm asking these questions so that I have a better understanding.

A little background . . .

You should find two files, /etc/passwd and /etc/groups ... (both of which contain bogus information, since they aren't the "real" files)[/i] ... which list (most of) the users in the system, and the groups.

Each login user has a numeric identification ... a uid ... and, similarly, groups have a gid. (The aforesaid files map these numbers to names.)

If you issue the groups command from the command-line, you will see all of the groups that you now belong to.

Standard Unix/Linux directory and file permissions distinguish between: owner, group-members, and everyone-else. (There are other, more advanced tools such as "Access Control Lists (ACLs)," but for now I'll just leave it at that.)

chown sets the "uid" and/or the "gid" that is associated with a particular filesystem entity. While entities can have only one group-id, users can belong to more than one group.

The user has ownership permissions... But the user cannot set the group the file will be in. If apache creates the files then the owner will be apache, and the group will be apache. No other user will have access except through "other" permissions.

As I understand Wordpress, it is a application started by the web server (hence, any files created will be owned by apache, group apache, and the permissions are owner,group, and others get none, though sometimes read access is allowed). This is one of the reasons Wordpress has such a poor security record - everything is owned by Wordpress which is running under the web server. All files owned by apache, group apache. Any hack of the web server (including the Wordpress CGI) gets access to everything (even anything stored in the database as it can do anything Wordpress can do in the database)

When you tell WordPress to perform an automatic update, all file operations are performed as the user that owns the files, not as the web server's user. All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.
And then read https://www.linuxquestions.org/quest...e-users-37043/

Ask if you have any questions.

Indeed.

On nearly every system, the Apache web-server runs with a uid/gid that is specific to it. (This user can't "log on" to the system at all.) Files made by WordPress are, from Linux's point-of-view, "made by Apache." Therefore, files that WordPress is to modify must be ... according to the chown command ... "owned by" Apache, and ... according to the chmod command ... read/write accessible to it.

If you can log-on to the web-server machine through the command line, consider making duplicate copies of all of that material into your home directory ... a place that Apache cannot get to.

Also consider using the chmod command to temporarily make "WordPress system files" read-only to Apache, except when you are consciously about to perform a WordPress update! (The files must be read/write when they are about to be updated, but need not be read/write at any other time. It's great fun to watch L33T H4X0RZ tell WordPress to do something nasty ... only to find that, at that moment in time, WordPress can't!)

It is one of the advantages that RH has over most other distributions...

RH uses SELinux to put apache into a compartment that doesn't necessarily get full access to its own files...

Using SELinux allows the administrator to set "httpd_sys_content_t" security label on the files apache can access... but this does NOT permit apache to modify the files, even though they are owned by apache. Files created by apache are created with "httpd_sys_rw_content_t" which does permit write - and the directories must also have that security type or apache cannot create the file.

If a file doesn't have "httpd_sys_script_exec_t" then it will NOT be executed as a CGI (makes it hard for hacks to plant executables for future remote control). And apache is not run with such permissions, so it cannot create such files.

Running under such labels also prevents apache from accessing any files it shouldn't (such as password files, user files... anything not explicitly identified as appropriate for access). Again preventing improper data access.

It takes a bit more care to set up, but makes the system MUCH more secure.