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.
Related
I have a webapp setup on cPanel/Apache/CentOS
If I set the permission of directories under document root to 755, it works OK. However, if I change any directory permission to 754 (revoke execute permission from OTHER group), the web server refuses to serve any file under the folder, resulting in 404 not found error.
Apache is running as the file owner, so why does it bother to care about the OTHER's execute permission?
Apache is running as the file owner, so why does it bother to care about the OTHER's execute permission?
Are you sure about that? Apache is almost never configured this way, outside of exotic setups like mpm-itk. The web server is usually configured to run as a separate user, often as www-data, httpd, or nobody. These users are not members of your group, so they rely on the "other" privilege mask.
Depending on your site configuration, you might be able to add an access control list to the document root to explicitly allow the web server user, or chgrp your document root to a group shared with the web server to use group privileges instead. (Or you might not. No guarantees.)
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
Currently I'm using 0750 for directories and 0640 for files. Is it possible to lower these permissions? I know this depends on the setup of the hoster (FTP/PHP/Apache user in same group?). But what is possible? Which permission Typo3 really needs for running correctly?
According to install tool the following folders should be writable:
fileadmin
fileadmin/_temp_
typo3
typo3conf
typo3conf/ext
typo3conf/l10n
typo3temp
uploads
uploads/media
uploads/pics
uploads/tf
There is no need for write permissions on typo3/. This is only needed, if you want to install an system extension (what you should not do) and for some .htaccess files which could be created by the install tool (create them by hand, or change permissions afterwards).
Usually your FTP-User and your Webserver-User are different. So they should be in the same group. So you need to set permissions to 0770 (directorys) and 0660 (files) so you can upload files via FTP and edit them via TYPO3. Otherwise you upload an file via FTP with 0630 - and you will not be able to delete that file via TYPO3.
My system is:
Ubuntu 10.04 / Apache2
The question is related to the sofware vftpd - an ftp server for linux (https://security.appspot.com/vsftpd.html)
I have installed vftpd and it works fine. I am having an issue though trying to understand why users are able to delete files which are owned by root. I have set up the ftp server with the option "local_enable=YES" and also "chroot_local_user=YES" so that the users cannot navigate outside their home directory.
The strange thing is that if a file is owned by root, the ftp users are able to delete it. Is a user able to delete any file in the home directory regardless of who owns it?
I want to prevent users from being able to delete files, or allow other users to only have read access to the home directories of other users.
If anyone knows the vftpd software and can help i´d be most grateful,
yours,
Rob
Have you checked which is the chmod of the files? If all files belongs to the same group, and the group have read and write privileges, any user can modify the files through ftp.
I have a java servlet. When it saves files, it saves them as tomcat:tomcat (in a linux environment). I actually need it to save it as sportsfan:tomcat as sportsfan is the FTP user and also needs access to create, modify or overwrite these files.
I thought about running tomcat as sportsfan:tomcat, but I'm running multiple applications under the one tomcat instance.
Perhaps the best way to do this would be to have the FTP user log in as part of the tomcat group. Would that be a correct way?
Please advise.
Adding your sportsfan user ftp to the tomcat group could be a good solution but before that check which are the modifiable files in you system with this permission and consider the security risks.
Another solution: Create a sportsfan group and add your sportsfan user to it. Then change the group of your upload directory and set it as setgid:
chgrp sportsfan upload
chmod g+s upload
After that the new files in the upload will be created with tomcat:sportsfan owner:group. It's not exactly what you asked for but changing the user id (setuid directories) is not supported on Linux. Wikipedia has a pretty good article about setuid and setgid directories. Futhermore, you have to set the umask value of the tomcat user to 000x (e.g. 0002) or a similar value which gives full access to the group.
3rd solution: set up a cron job which changes the permission in every n minutes.