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
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.
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.
On a mac in terminal when executing:
chown apache uploads/
I get the error:
chown: apache: Invalid argument
The foder is on a shared web server. I need to change the owner of the folder because otherwise my PHP script for creating simple text files will return a permission denied error. Please don't suggest chmodding the folder to 777 (which does work), since almost all advice against it.
Is it possible that the server doesn't run scripts as the user 'apache'? How can I find this out?
"Invalid argument" makes me think this directory is on an HFS+ volume with owners disabled; you won't be able to change it in that case. You may be able to switch owners on, although it's possible that requires reformatting.
(The advice to check /etc/passwd is wrong, or at least inaccurate, on OS X; you need dscl . list /Users.)
There are two things you might want to check:
1) Is there a user called apache? Maybe it's httpd. You can search /etc/passwd. (Or whatever your platform uses to store user names, you didn't mention your operating system.)
2) What user do scripts run as? You can check this by running a test script. For example:
#/bin/bash
echo Content-Type: text/plain
echo
id -a
If you save this as test.cgi and put it in a CGI directory, you should be able to run it and get it to tell you what user it's running as.
Currently I am working on a C linux daemon that takes user input for an SQL connection string, then stores the information into a local conf file (client side). The purpose of the daemon is to submit data to an SQL database at a set interval in that every time the daemon is loaded it will look to the local conf for the SQL connection string. Also by using the command line argument -c, the user can reconfigure the SQL connection string in the event that the information changes. Would anyone be willing to share a way of securing this conf file so that it is not plain text. Keep in mind that I still need to be able to access and read in from the conf file as there is other conf settings present. Thanks in advance guys.
Edit: I do eventually plan to use SSL to submit the data between the client side and the SQL server.
The (only?) way to secure the file is to change its permissions to make it readable only to the user that runs the daemon.
Eg. if you are running the daemon as user 'foo' and group 'foo', you should:
chown foo.foo my-conf-file
chmod 600 my-conf-file
(Or even chmod it to 400 to prevent accidental modification, but I guess in this case you'll lose the -c option functionality).
NOTE: Also remember that it is quite dangerous to pass connection strings on the command line since they will be visible from the process listing!
You could also use some GPG stuff to encrypt the file, but I don't see the point there since then you have to protect the key you use to decript the file, and you get the exact same problem as before.
If you have no place to keep your secrets, cryptography will not help you. If your daemon is somehow able to decode password not using any secret, then anyone can do this too. So you have to rely on system protection, such as file access mode flags to keep keys.