I have multiple PHP applications hosted in Apache on Redhat 8.
Some of the libraries used in these web apps generate files owned by Apache.
-rw-rw-r--+ 1 apache apache 35 Dec 16 12:54 cf8d2#setClass.cache.php
-rw-rw-r--+ 1 apache apache 35 Dec 16 12:54 c8dds#setSchemeId.cache.php
I have a deployment process which deletes a release before deploying the new release. Since these files are owned by Apache, the deployment fails as the webadmin user cannot remove these files.
The app files themselves are owned by a user/group called webadmin.
-rw-rw-rw- 1 webadmin webadmin 2848 Dec 16 12:59 index.php
Is the a way to force Apache to create files owned by webadmin?
You can add the webadmin user to the group of apache. Then you should have enough permissions. Otherwise you could use ACLs and give the user permissions for that directory.
ACLs on Redhat 8
Here is a manual how to use the ACLs. I think that is the easiest way. Otherwise you have to run the deployment with higher privileges.
Or you give the user sudo rights to the folder like this.
Sudo rights in a particular directory
So there are some ways to solve the problem.
Related
One of our security expert has run vulnerability detection script on CoreOS and found few recommendations (Note this script is initially designed used with Linux OS)
Some of the VA issues reported by tools as below.
PASS_MAX_DAYS in /etc/login.defs must be set to 60
Field 5 of /etc/shadow must be 90
CoreOS doesn't allow me to edit /etc/login.defs as root user. The file is read-only for core and root users. I know this is in-vain as CoreOS uses ssh key based login. However I would like to know whether there is any other way to edit this files as I need to deal with few system files to fix more issues.
Do I need to use cloud-init tool to modify this file ? or is there any other alternative to harden CoreOS ?
https://groups.google.com/forum/#!topic/coreos-user/87fluJrTuJE:
These types of files in /etc are actually symlinks pointing to files in /usr. This allows CoreOS to update them via auto-updates, but also give you the ability to break the symlinks and stick a customized file in its place. You can see this by listing out the directory:
$ ls -la /etc/ | grep login
lrwxrwxrwx. 1 root root 32 Nov 8 19:00 login.access -> ../usr/share/shadow/login.access
lrwxrwxrwx. 1 root root 30 Nov 1 06:14 login.defs -> ../usr/share/shadow/login.defs
Obviously, edit these only if you know what you are doing. You should be able to do this cloud-config/ignition if you need to automate it.
Both of those recommendations have to do with login passwords. We do not recommend you use passwords at all and nearly all setups of CoreOS Linux use ssh keys instead.
For my desktop machine, I'd like to be able to access files in my home directory in a browser.
I have set the Apache DocumentRoot to my home, but I get logically a forbidden page. I tried to add www-data user in my group, with the same result.
I would not prefer give full access to any user in my home.
So how should I proceed to let apache read my home dir?
$ ls -la /home | grep gael
drwxr-xr-x 44 gael gael 4096 mars 17 22:30 gael
$ groups www-data;
www-data : www-data gael
The error log:
[Tue Mar 17 22:43:06.592819 2015] [authz_core:error][pid 4572] [client 127.0.0.1:59677]
AH01630: client denied by server configuration: /home/gael/
apache conf:
<VirtualHost *:80>
DocumentRoot /home/gael/
</VirtualHost>
make sure that the user running the webserver has full read permissions to all files they need to see. they will also require execute permissions for any directory they need to traverse into.
so it seems that you have added the www-data user to your own group, which should fulfill the above.
be aware, that a new group-membership does not take effect immediately: interactive users need to login again, a daemon needs to be restarted (thus: restart apache). the w32 way (just reboot) will also work.
btw, exposing your home via a webserver seems like a bad idea: anybody who can access the webserver (usually anybody on the same net) will be able to see your home-directory. make sure that you add extra security (password protection, encryption,...).
btw, did you know that the ~/public_html directory is traditionally exported by your web-browser as ~<user> (so if your login name is "gael" you can access this directory via http://localhost/~gael/). if the directory does not exist, just create it and make sure that you set its group to www-data. this is a much more secure way to share some data via the web.
I'm trying to setup a basic Ubuntu 14.04 web server but am having trouble setting file ownership correctly. I want the Apache user (www-data) to have ownership of the web directory (/var/www) and my user to have membership in the apache group. I want both my user and Apache to have the ability to read and write to the /var/www directory.
This is the permission and ownership for the directory I want to share:
drwxrwxr-x 3 www-data www-data 4096 Aug 23 13:39
I've added myself to the www-data group and recursively set permissions on the web directory to 775. Apache is able to read and write but my user, when attempting to add a file over SFTP is getting "permission denied" messages.
What am I doing wrong and should I have ownership setup differently?
Hi, two things to check:
is your user a member of /etc/group:www-data
in /etc/sshd_config, is the user have authorization by pam or AllowGroups+AllowUsers ?
I am learning Hadoop, and would like to try the pseudo-distributed operation
When I try to use start-all.sh to start the Hadoop daemons, should I use a non-root user like foo-user or use root.
Using root has no problem, however, I am a little bit concerned about it.
Using a non-root user, foo-user, it complains that it doesn't have permission to files
/var/run/hadoop/hadoop-foo-user-namenode.pid: permission denied
/var/run/hadoop/hadoop-foo-user-tasktracker-foohost.pid: permission denied
It was trying to create these two files in the directory /var/run/hadoop
I tried vim /var/run/hadoop/testfile, and couldn't save. So turns out that foo-user doesn't have permission to write at /var/run/hadoop
I checked the permission of /var/run/hadoop
drwxrwxr-x root hadoop 4096 Feb 8 23:42 hadoop
foo-user is in group hadoop, so should have write permission to /var/run/hadoop. Indeed, several other id files are created there, like the ...jobtracker.pid
So should I use root for start-all.sh or there is something wrong with the permission ( I am really confused)?
It's not recommended to start Hadoop as the root, below is quoted from Yahoo's Hadoop tutorial:
The user who owns the Hadoop instances will need to have read and
write access to each of these directories. It is not necessary for all
users to have access to these directories. Set permissions with chmod
as appropriate. In a large-scale environment, it is recommended that
you create a user named "hadoop" on each node for the express purpose
of owning and running Hadoop tasks. For a single individual's machine,
it is perfectly acceptable to run Hadoop under your own username. It
is not recommended that you run Hadoop as root.
Even though foo-user is in the group hadoop in the Linux filesystem, you still need to make sure
that foo-user is also a group member in HDFS (by default the group is called supergroup), you'll see what the group is when you do hadoop fs -ls path_to_your_data.
group as well as user needs to be hadoop. Here you have:
drwxrwxr-x root hadoop 4096 Feb 8 23:42 hadoop
so change the root into hadoop (curently i don't have access to any linux machine so I can't say exact commands), then make yourself sure that hadoop user is able to create filies and directories within /var/run/hadoop. I strongly recommend to run it s non-root user.
Hope you are good. I have Xammp on fedora and changed owner of opp/lampp/htdoc to root. Why I did so because whenever someone creates new folder through sharing, they don't have permission to dynamically create folder or files or to write images. Then I run command
chmod -R 777 /opt/lampp/htdocs
But when system goes to restart then I again need to run this command. So avoid again and again run this command I changed the owner on "opt/lampp/htdocs" and run
chmod -R 777 /opt/lampp/htdocs
Now, whenever server restarts, assigned permissions don't need to be set again and again. That is resolved.
I have an issue, that old directories can be used to write something. But if any network user creates new directory under htdocs, that new directory needs to be changed the permission for it.
previously created, and can use this one directory to run script to create files
drwxrwxrwx 2 root root 4096 2011-06-15 14:09 aaa
Newly created, cannot be used to run a script to create image or to write anything
drwxr-xr-x 2 root root 4096 2011-06-17 15:17 aaaa
drwxr-xr-x this one is really annoying to me for each newly created folder in htdocs :(
Just to let you know that my htdocs user and rights are:
drwxrwxrwx 101 root root 4096 2011-06-17 15:17 htdocs
Why is it so? Can anybody please help me to figure this problem out? I am waiting for quick response anxiously.
First off, you should investigate what permissions you really need - chmodding everything to 777 is a security risk as it will allow any user to write inside of your web root.
However, to address your actual question of the default permissions when a new folder is created by a user, you want to adjust the default "umask" which determines such things.
This question has some information for changing it for the Apache user (if a "network user" is a user creating new files and directories through the httpd process):
Setting the umask of the Apache user
If you need to adjust it for other users or processes, the solution will be similar.
Good luck!
Edit
Since you're on Fedora, try this: (from the question I linked above)
[root ~]$ echo "umask 002" >> /etc/sysconfig/httpd
[root ~]$ service httpd restart
The first command will add that line to the /etc/sysconfig/httpd which is a permanent configuration file, and the second command will make it active.
You are tackling the problem from the wrong side. Restore your apache configuration to use apache.apache as default user/group, and set your samba server to use those credentials when someone write to your document root.
If you are using nfs or another posix compatible filesystem, use chmod g+s to keep all files readable from your apache server.
Try it:
#umask 000
have a good time!!