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).
Related
Using Windows Server 2008 version R2 Standard / Service Pack 1.
I have a shared folder containing the home folders of users. This is called user$.
I have the following share permissions on user$: Everyone: Read/modify
I have the following file permissions on user$:
CREATOR OWNER: Deny: Change permissions and take ownership: Subfolders and files only.
CREATOR OWNER: Allow: Everything except take ownership and change permissions: Subfolders and files only
SYSTEM: Full control: This folder, subfolders and files.
BUILTIN\Administrators: Full control: This folder, subfolders and files
Domain Users: Allow: Traverse, list, read, read attributes, read permissions, create folders: This folder only
I have applied this to the user$ share and replaced all child permissions with inheritable entries. So why do users still have permission to change permissions? Take ownership is not allowed and seems to work as expected.
The reason I need to do this is because something (still unknown) is changing the permissions in a way that makes the files inaccessible to users and messing up a lot of processes. This seems to happen randomly on a daily basis to about 5-10% of users.
Thank you.
The Owner has an implict Read and Change permission access and has precedence over Deny permissions.
Check the effective access rights of an user to the file.
I suggest you enable Permission change auditing and see what is causing the issue.
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.
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.
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.)
it happens often that an silverstripe installation does not have the right permission to write in the assets folder - e.g. for saving resampled images...
I wonder what is the best permissions setting for the files and folders in assets/ to solve that problem.
you read so many different things when you google...
can I just chmod the whole assets folder and its contents to 0777?
or do files and folders need different permissions?
is there an recommendation for Owner and Group?
can I have "dangerous" settings?
Rule of thumb:
Stuff the webserver needs to write (assets/, silverstripe-cache/) need to be writable by the server
Stuff the webserver needs to read (framework, cms, modules, custom code,...) should only be readable by the server
chmod 777 will work for the writeable parts, but you might want to set the folder's owner to the webserver's user (www-data, nobody, or whatever this is on your system) plus chmod 755 to avoid global write permissions.
See if your hosting provider will install the mod_suphp (suPHP) Apache module, then you don't have to worry about setting dangerous folder permissions: http://www.suphp.org/Home.html