Help with SVN+SSH permissions with CentOS/WHM setup - linux

I'll try my best to explain how I'm trying to set up this system.
Imagine a production server running WHM with various sites. We'll call these sites... site1, site2, site2
Now, with the WHM setup, each site has a user/group defined for them, we'll keep these users/groups called site1,site2 for simplicity reasons.
Now, updating these sites is accomplished using SVN, and through the use of a post commit script to auto update these sites (With .svn blocked through the apache configuration).
There are two regular maintainers of these sites, we'll call them Joe and Bob. Joe and Bob both have commandline access to the server through thier respective limited accounts.
So I've done the easy bit, managed to get SVN working with these "maintainers" so that when an SVN commit occurs, the changes are checked out and go live perfectly.
Here's the cavet, and ultimately my problem. User permissions.
Through my testing of this setup, I've only managed to get it working by giving what is being updated permissions of 777, so that Joe and Bob can both read and write access to webfront directories for each of the sites.
So, an example of how it's set up now:
Joe and Bob both belong to a group called "Dev". I have the master /svn folders set up for both read and write access to this group, and it works great. Post commit triggers, updates the site, and then sets 777 on each file within the webfront.
I then changed this to try and factor in group permission updates, instead of straight 777.
Each folder in /home/site1/public_html intially gets given a chmod of 664, and each folder 775
Which looks a little something like this
drwxrwxr-x .
drwxrwxr-x ..
drwxrwxr-x site1 site1 my_test_folder
-rw-rw-r-- site1 site1 my_test_file
So site1 is sthe owner and group owner of those files and folders. So I then added site1 to Joe and Bobs secondary groups so that the SVN update will correctly allow access to these files.
Herein lies the problem now.
When I wish to add a file or folder to /home/site1, say Bobs_file, it then looks like this
drwxrwxr-x .
drwxrwxr-x ..
drwxr-xr-x Bob dev bobs_folder
drwxrwxr-x site1 site1 my_test_folder
-rw-rw-r-- Bob dev bobs_file
-rw-rw-r-- site1 site1 my_test_file
How can I get it so that with the set of user permissions Bob has available, to change the owner and group owner of that file to reflect "site1" "site1". As Bob belongs to Dev I can set the permissions correctly with CHMOd, but It appears CHGRP is throwing back operation errors.
Now this was long winded enough to give an overview of exactly what I'm trying to accomplish, just incase I'm going about this arse-over-tit and there's a far easier solution. Here's my goals
2 people to update
multiple user accounts specified given the structure of WHM
Trying to maintain master user/group permissions of file and folders to the original user account, and not the account of the updatee.
I like the security of SVN+SSH over just SVN.
Don't want to run all this over root.
I hope this made sense, and thanks in advance :)

Try:
$ chown -R site1:site1 /home/site1
This will recursively change all files in that directory to be owned by the "site1" user in the "site1" group.

Related

Permissions issue in Linux with root vs other admin acct

I know there are many different examples on here, but I am having trouble with my specific example.
I am trying to copy some files from a specific folder on my Windows PC to my VPS (Virtual Private Server) by using SSH via WinSCP.
The folder that was created looks like this:
As you can see there are permissions as root as the owner. I login as a different user named Smith. When I try to transfer files from the PC to the folder, I get access denied.
A few things I tried:
I deactivated root for security purposes so I can't easily login as root. I could reactivate it temporarily to do this exercise, but trying to find a different way.
Even though Smith is an Admin, that account can't seem to move files to this directory when logging in
I tried sudo -i for root but root doesn't share any groups with Smith and not sure what to do other than making it 777
I know I can just blow out security and make it 777, but I am guessing that's bad practice?
Maybe I missed something in what I did above, but what's the best way so that Smith can copy files to the directory above when logged in as Smith, even though there are no groups shared with root that could be used right now, and I don't want to just blow security wide open?
If you only want to write the directory as the user Smith, then the simplest solution is probably to make Smith the owner of the directory. Assuming you can login to a Linux console with sudo permissions, you can deploy that using a command something like:
$ sudo chown Smith bookstore

Force files creation in a folder to have a fixed group:user

I'm on linux.
It is possible to force a folder to have a fixed couple of user:group for new files created ?
The issue is that every time a file is created by the use www-data it is the not accessible to my main user.
I have added MYUSER to www-data group and www-data to MYUSER group, however this is not enough.
I would like that all files under my /www/ folder were created with MYUSER:WWW-DATA couple regardless if it created by me or by apache.
is it possible ?
You need to use acl to do that
https://wiki.archlinux.org/index.php/Access_Control_Lists
it will not always create the files as another user then the user who created the file, but you have control of which users have default permissions to the files

WordPress unzip_file() results in mkdir_failed (permissions)

I am creating a WordPress framework that has an auto update facility. When the system updates the framework, it downloads a .zip file (works ok, stored in a temp folder), and afterwards tries to extract that zip file to a place within the theme. When unzipping, it throws an error complaining about not being able to create a directory ("mkdir_failed").
The parent of target folder has permission "775" for user "bitnami" and group "bitnami";
root#linux:/home/bitnami# ls -al /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus
...
drwxrwxr-x 6 bitnami bitnami 4096 Oct 23 14:02 nexusframework
...
And I tried to put the "daemon" user in the "bitnami" group;
usermod -a -G bitnami daemon
Which indeed is assigned correctly I would say, as i see:
root#linux:/home/bitnami# id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon),1000(bitnami)
So; if the "daemon" user is in the "bitnami" group and the folder has 775 access rights, then why does it fail with "mkdir_failed"?
(note; assigning "777" to the parent folder solves the problem, but this is not an option because of security).
Thanks!
- Gert-Jan
update;
After doing more investigation on Linux in general, I read that Linux automatically creates a 'private' group for each user (so bitnami group for the bitnami user, etc.). I don't know if the problem is caused by the fact that I was trying (and apparently succeeded?) to add other users to the same group or not.
update;
See my answer below on how I resolved my issue.
Ok, thanks for all the comments. I eventually decided not to continu my investigation but to head for another direction, as having to rely on the container's folder to have "775" permission would be unwise for the framework (many clients would have 755 instead, so getting this to work for a group is nice but would eventually not solve my problem).
Instead I further investigated how WordPress themselves download and unzip themes and decided to follow that route.
The key problem i was trying to tackle, was to not have the unzipped files be owned by the 'daemon' user, but by the 'bitnami' user. The reason why it "impersonated" to the daemon user, was because i manually told the code to use the "direct" fs_method (as it appears, WP offers various ways to interact with the filesystem, where the easiest one is 'direct', see here). However, using the 'direct' FS_METHOD is the core reason why I have this problem, as that one will use the credentials of the webserver (the 'daemon' user in my case). So by using a different FS_METHOD, I know am able to unzip the files in the folder, using the correct 'bitnami' user (since the container is owner and has permissions (775, or 755 wouldn't matter) now my problem is solved. Note that instead of writing directly to the filesystem, now PHP will use FTP (see here).
Does it work if you change the group of the folder to daemon?
chgrp -R daemon /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus

joomla directory permission problem

I have installed joomla on my new account . All the files are showing the FTP username as the owner of files . But when i go to joomla admin section and check directory permissions , it says the few folders are unwritable .
Does it mean that admin page is using different user than FTP username
Its not about ownership, usually its about permissions. If you want to understand it all - there is a quite extensive FAQ
http://forum.joomla.org/viewtopic.php?t=121470
Short one - look into the the test results - note the files and directories to be changed. Depending on the security configuration of your Web server the recommended default permissions is:
755 for directories
644 for files
change them. For Filezilla (a free ftp client - my best guess on what you are using) a good tutrial how change file permissions is :
http://www.codeunit.co.za/2008/07/18/remotely-changing-multiple-linux-file-permissions-with-filezilla/
Since the owner usually has the most rights, changing the ownership of all files to the http-server process owner could also work' but then again - you would have to do this each time and its not possible via ftp.
Yes, if this is hosted on apache, the apache server usually runs as user www-data.

Need to change permissions on *nix system to 777

Have a folder and files as follows:
Folder:
drwxrwxrwx 3 me 153157 8 Aug 17 14:17 Nugget
File within Nugget:
...
-rw-rw-r-- 1 web web 24 Aug 17 14:17 nugget.php
I need to change permissions on nugget.php to 777 as per the documentation.
$ chmod 777 nugget.php
chmod: nugget.php: Operation not permitted
Suggestions?
You could do this as root but I suggest to sit back and think about it for a moment. Anyone with access to your computer will be able to change this file in any way. Crackers get paid money to find files like that and abuse them.
Usually, your problem is that the web app needs to read the file and some user needs to be able to write it. In this case, chown the file to the user and leave the group as web and set the permissions to 640 (local user can read+write, web can only read).
Unless you are in group web, you do not have permissions to write that file. If you own the system, you can use sudo to accomplish what you need. However, if you had sudo access, you probably wouldn't be asking.
Since you own the directory, you can delete the file. So one workaround would be: save the text of the file somewhere else (in another window). Delete the file. Recreate the file in an editor, pasting in the text. Save. That should do it. However, it's possible since this is a script that doing this would break the script (it might need to run as user 'web').
The safest alternative is to ask the system administrator to add you to the group "web", or else to have him or her change the group of the file to a group that you are in.
Your account (the one you logged in as) does not seem to have permissions on that file.
It's owned by "web", and you're not logged in as that user or that group. The permissions on that file for accounts that are not the owner or that do not belong to the web group are listed as "r--", which means the account that you logged in as can only read it.
So, login as root or "web" and perform the same operations.
sudo chmod 777 nugget.php ??

Resources