is there any possibility to change the permission when a folder in fileadmin is created per ftp and now you cannot copy a file into this folder?
TYPO3 is version 8.7
Greeting
Volker
You will have 3 Options:
Create the folder with a user that is in apache/nginx/php group, respectively dont use the FTP-Root user on creation.
Connect via FTP and fix the permission of the folder.
Connect via SSH and fix the permission in terminal context.
Regards
Ribase
Your problem is not TYPO3 specific. It's an unix problem.
or better: you need to understand rights management on unix systems.
there are three levels: owner, group, everyone
for each level you can define the possible rights (read, write, execute)
in octal notation this matches exact the bits of coding
rwxrwxrwx
||||||+++-- everyone
|||+++----- group
+++-------- owner
Also each file holds an owner and a group.
Folders are a special kind of files which need execution rights to see the content (list of files).
Then there are default bits that are set if a file (or folder) is generated. These bits can be configured with the umask command - or the program you create the file. with TYPO3 you can define it in the install tool.
Maybe your FTP program has similar configuration.
Depending whether your FTP-user and the PHP/Apache-User are identical, share one group or have nothing in common you need to set the bits for each file to grant access each other.
be aware: independent from your BE-user which you use for login in TYPO3 BE, any file action in the BE (or FE) is done with the apache/PHP user, which probably is not your FTP user.
In a shell you have the commands chmod to change the assess bits and chown to change the owner and group of a file. (hint: chgrp will only change the default group assigned to new files)
If you do not have the writing rights for folder and file you can not change any rights of a file. Especially not the right to modify a file (remember: folders are files).
The best option to modify the rights is to use the same user than the file was created (as an owner you have the most rights).
Second best is to be root. Root is allowed to do anything, but therefore you should avoid being root, as you also can destroy anything.
Related
Question is about configuration of RHEL Operating System, or adding a custom script, I suppose.
I want to allow user1 to launch my program that reads a settings file owned by another user.
The final scope is:
to avoid user1 to be able to read the settings file.
to allow user1 to launch my program executable.
I supposed that my program and my settings file could be owned by root, giving user1 the right to execute the program. But If I do this, will the program be able to read settings file owned by root?
Is it there a solution to this problem, without customization of my program executable?
Edit:
The scope is to protect settings file content, but allow the user to use the application. Another way to solve the same problem with different question is:
Suppose that I give root privileges to exe and settings file, and then start the exe automatically during boot. User 1 will not be able to read settings file (this is what I want). Suppose that the exe is a terminal application that prints standard output and expects commands as standard input. Is it there a way, for user1, to read standard output and write standard input to the exe previously launched by root?
An attempt of an answer. Imagine /home/user/program is the program that should be run by user1, and /home/user/private-config-file the file that the program should be able to read (on behalf of user1) but not directly readable by user1.
In these configuration, I think the following should work:
create a custom group private-group (as root):
~ addgroup private-group
make the configuration file belong to private-group and group-readable (probably as root, unless your normal user is set to belong to the group too):
~ chown :private-group /home/user/private-config-file
~ chmod g+r /home/user/private-config-file
make the executable belong to the group and setgid (probably by root as well):
~ chown :private-group /home/user/program
~ chmod g+s /home/user/program
The program should not be in a scripted language, since setuid/setgid do not work in this case.
Using this, the program, when running, will have an effective group ID private-group, which should be enough to let it read the configuration file.
As far as I know, this should get you going, but you need to keep in mind that:
if there is any way for user1 to use the program to read arbitrary files, then your configuration file could be opened;
the program might re-write its configuration file, including the private bits, in a specific location, in a way that would be readable by user1;
any user that can execute /home/user/program will be able to use the configuration file (even if not read it).
IMPORTANT setuid/setgid processes are much harder to write and use in a secure way than you would believe...
I should again emphasize that if you have significant security implications of leaking the contents of the configuration file, you really should think and tread very carefully.
Quoting How to determine if you can write to a file with SFTP because of your group? ,
You could do mode & 00002 to see if a [directory] is writable by the public
and you could get a directory listing to and see if the owner of .
matches the user that you logged in with (although stat doesn't
usually return the longname for SFTPv3 servers, which is what you'd
need to get the username from that) but what about group permissions?
In the answer to that post it was suggested that a better way to test the writeability of a file with SFTP was to actually open that file for writing. eg. something analogous to fopen('filename.ext', 'w');.
My question is... what's the best way to determine the writeability of a directory with SFTP? You can't open a directory for writing like you can a file. My best guess: just attempt to upload a temporary file in the directory in question?
Like maybe use SSH_FXF_CREAT and SSH_FXF_EXCL? Altho the possibility that the file might already exist kinda complicates things. I guess a directory listing could be obtained and then one could attempt to upload a filename that doesn't exist but, the fact that this would require read permissions not withstanding it'd also not work as well if the directory was super large.
Any ideas?
What about a login script which would do a touch on that directory with that user?
If sshd would be used you could use a pam_script (pam auth module to execute a script) simply to simply do a touch testing_file_creation in your directory. You would need to add into your pam sshd configuration.
If the directory would not be writable you would get a message during your login
touch: testing_file_creation: Permission denied. Of course, you could do more fancy stuff with that but this would be the very basic.
After successfully mounting the directory (ZFS remote storage) from one of the server, I'm getting an "Operation not permitted" error when I try changing the ownership of the directory. I'm using the following command:
To mount the remote directory:
mount -t nfs 10.1.32.33:/dir/temp/tools /home/materials
After mounting the directory, the contents are belongs to nobody:nobody
I want to change ownership so I can run the installer inside the directory.
I'm using the command below to change ownership but it's not working:
chown -R otm:otm materials/
I can always upload the file to the server without using the ZFS storage, however I want to start making a central installer repository so I don't need to upload the files/installers for future server install. I appreciate your help guys.
NFS servers by default do not allow root access to files - root is normally mapped to "nobody".
See "root squash":
Root squash[2][3] is a reduction of the access rights for the remote
superuser (root) when using identity authentication (local user is the
same as remote user). It is primarily a feature of NFS but may be
available on other systems as well.
This problem arises when a remote file system is shared by multiple
users. These users belong to one or multiple groups. In Unix, every
file and folder normally has separate permissions (read, write,
execute) for the owner (normally the creator of the file), for the
group to which the owner belongs, and for the "world" (all other
users). This allows restriction of read and write access only to the
authorized users while in general the NFS server must also be
protected by firewall.
A superuser has more rights than an ordinary user, being able to
change the file ownership, set arbitrary permissions, and access all
protected content. Even users that do need to have root access to
individual workstations may not be authorized for the similar actions
on a shared file system. Root squash reduces rights of the remote
root, making one no longer superuser. On UNIX like systems, root
squash option can be turned on and off in /etc/exports file on a
server side.
After implementing the root squash, the authorized superuser performs
restricted actions after logging into an NFS server directly and not
just by mounting the exported NFS folder.
In general, you DO NOT want to disable root squash unless you REALLY know what you're doing as there are serious security issues you can create if you do that. And since you didn't even know it exists...
(And that mention of /etc/exports is an extremely limited statement that is wrong on many systems - like Solaris.)
I need some suggestions about Joomla's files and folders ownership.
I'm working with a Joomla 2.5 website, hosted on a linux-apache server which hasn't suPHP module.
After one year of usage some files are owned by apache-user, and others by the ftp user.
I request to give the ownership of all files to the ftp user, but joomla (the apache user, after all) can't update system, install extensions or upload images.
How can i set the ownership of files?
Thank You
You will either need to talk to your hosting provider to change the file/folder ownership for you (which they should do), else if you are managing the server yourself , then you can do this using the following SSH command:
chgrp -R OWNER FOLDER
-R means recursive so it will also change the ownership for any sub directories and files
OWNER is the name of the server which you will need to add
FOLDER is simply the name of the folder you wish to apply this change to.
As for the command line tool, I like to use Putty
Hope this helps
As we all know that with shared web hosting other users (websites) files could be revealed to others if 'others' have the (read) permission .
I think 0700 or 0711 permission is the best way( in shared hosting) to protect important files the contain secret information .
I suppose that the server is using suPHP or any similar module so that keep the UID of the process is the same as the owner of the files being accessed.
So what do you say ?
You are correct. 700 would ensure nobody can read/write/execute that file, except the owner. So that would be good enough! In case it is to be executed, 711, else, 700.
However, if some operation involving that file fails, you should consider 711.
EDIT:
As you have mentioned, if it contains a connection string, you can safely assume that nobody needs to be given write privileges, and give everyone execute privileges.
So, 511(which is r_x __x __x) should do it.
You'll need execution rights only for directories, if your files are PHP source files you certainly do not need execution rights.
0640 and 2750 are usualy good rights for respectively Files and Directories (the 2 in the directory rights make the new files inherit user & group of the directory).
That is for files:
-rw-r-----
And directories
drwxr-s---
Which is right if the webserver is using the group rights and the FTP-or-such user being the owner. With Suexec and such you could maybe adjust these settings depending of who is the owner and who is the web reader (user? group?), the web reader does not need write access, except maybe on some specific directories depending on the application.
And do not forget files & directories rights are only one point in separation of user in a shared envirronment. For PHP envirronments using per-user open_basedir settings, temporary files and upload directories and per-user session directories is always a good idea (that can be defined in per-user virtualhosts).