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.
Related
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.
I have implemented a restful API where i receive a website and return path to screenshots
I am using PhantomJS v 2.0.0 development to make the screenshots. I am making a console command that is executed with a secured, system()-like function. I use SU to log as a user 'phantomjs', which is restricted to use only specified commands, and then call my phantomjs script to render webpages as jpegs. The files outputted are owned by 'phantomjs' and have permissions set to 644. We have added the user 'phantomjs' to group www-data.
We are putting lots of webshots in a directory, and separate them alphabetically in sub-directories.So far so good. Our work scenario requires that we occasionally delete webshots.
So i implemented a restful delete-api which clients can use to delete their webshots. The real problem emerges from the fact that the files are owned by 'phantomjs' and with permissions set to 644, we can't delete the files through www-data. Since 'phantomjs' is in the same group with www-data, we need the permissions to be set to 664 in order to be able to unlink() those.
We wouldn't like to allow the user 'phantomjs' to use chmod or rm, because this would go against our design idea to restrict the user maximally, since this user runs shell commands.
We don't like the solution to run a cronjob that changes file permissions, because the server is pretty busy, and this solution is very undesirable and should be our last resort/
We tried using ACL making every file in webshots/ dir to have default permissions of 664, but this didn't work with our NFS as expected. Upgrading the NFS is not an option for me right now.
We tried umask 002, but this worked only with files created through the shell, so it couldn't help us either.
I've noticed that if i save an empty file through sublime-text , file permissions are 664.
If i save a screenshot with phantomjs, f.p. are 644.
My questions are:
-What governs default file permissions, the running process itself or some user preferences from which you run the application?
-Can you give me any more ideas how to delete webshots securely or make 'phantomjs' owned files have perms 664 without giving the user too much 'dangerous' permissions.
Any help would be highly appreciated.
Thank you.
After uploading .xls file to the server it becomes read only. How to make it back read/write.
u can use chmod() php function.
simply type smthing like that:
chmod("/dir/file.xls", 0777);
more about it in documentation:
http://php.net/manual/en/function.chmod.php
You have to check what read only really means in this case - is it lack of write permission (then use chmod to set one after all) or maybe your file is owned by someone else (which often happens on incorrectly configured hostings, where uploads are handled by httpd, not the user owning file hierarchy. If you got shell access do this:
$ ls -l
to list the files and see who owns it, then check what is your ownder id:
$ id
if these do not match, then you may need to reconfigure your server
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).