I have a very simple mod_wsgi python application that tries to write to a file:
tempfile = open('temp.txt', 'w')
This fails with
IOError: [Errno 13] Permission denied: 'temp.txt'
The folder with myapp.wsgi has world-writable permissions (777). I can write to a file from a simple PHP test script. This is running on Mac OSX 10.6 Snow Leopard, so as far as I know, there are no additional protection mechanisms in place (SELinux, AppArmor, etc.).
Why are write permissions denied ?
Yep, the solution to the problem is to use full paths to spcify file locations (and, just to be on the safe side, to specify shell commands you might be using in system call (or popen) calls), as the $PATH might not be what you expect it).
Related
I've made a fresh install of nextflow in a new computer, and I was trying to test the nf-core/rnaseq pipeline, but I am receiving the following error when executing:
Error executing process > 'NFCORE_RNASEQ:RNASEQ:INPUT_CHECK:SAMPLESHEET_CHECK (samplesheet.csv)'
Command error:
.command.sh: line 3: /media/Data/nextflow-rnaseq/rnaseq/bin/check_samplesheet.py: Permission denied
I've checked the permissions for the file, and has all the executing permissions:-rwxrwxr-x. I've also tried to execute it using both my working environment and singularity, and keep finding the same error.
I've also tested my own pipeline, with another project root folder and its own bin folder with custom scripts in there, and I'm having the same error.
Does anyone know if I'm missing something I should have done to make the scripts in bin accessible to nextflow?
Nextflow version: 22.04.4.5706
As Steve pointed out in a comment, the issue was related to how the filesystem was mounted (noexec), and fixing that solves the problem
I'm trying to run the SSHFS command in Cocoa app. I already put the SSHFS command in NSTask and but i got some error when executing the command:
RSA host key for IP address 'xyz.com' not in list of known hosts.
ssh_askpass: exec(/usr/libexec/ssh-askpass): No such file or directory
Permission denied, please try again.
ssh_askpass: exec(/usr/libexec/ssh-askpass): No such file or directory
Permission denied, please try again.
ssh_askpass: exec(/usr/libexec/ssh-askpass): No such file or directory
Permission denied (publickey,password).
remote host has disconnected
mount_osxfusefs: failed to mount /Volumes/Drive_Test#/dev/osxfuse4: Socket is not connected
In this case i think my app cannot find out the ssh_askpass. My question is how to run this file? Any suggestion would be appreciated. Thanks in advance.
ssh-askpass is an X11 application which is not directly compatible with MacOS. You can install a custom ssh-askpass in the same path, though it's a bit of a hack. Here is one implementation, though I can't vouch for its integrity or security, or compatibility with current MacOS. (See also blog at https://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_os_x_more_secure by the same author with forays into other possible approaches.)
A better and more modern solution is to let the MacOS keychain handle things for you. See e.g. SVN+SSH, not having to do ssh-add every time? (Mac OS) (not just for SVN obviously).
I've written a cgi script that processes data that is generated by another program. The problem is that this file is located outside the cgi-bin. How can I make sure that my perl scripts can read this file? I've already tried changing the permissions of this file and I also tried to make a link in the cgi-bin folder but Apache is too smart for that. I guess possible solutions are:
Edit the Apache config file in a way that Apache can read files outside the cgi-bin.
Run the cgi script with a 'portable' webserver. Like you can do with python (python -m http.server [port]). Unfortunately this does not execute the perl cgi scripts.
I'm kind of stuck how to do either one of the solutions.
Your CGI-script could access anything on your OS unless you run the apache under a sort of jail, in this case the your can read anything in the jail. (Of course, if the apache process has permissions to read the file).
e.g the next simple script will print out your password file
use strict;
use warnings;
use CGI;
my $q=CGI->new();
print $q->header();
print qx(cat /etc/passwd);
About the modern perl web-app development, read the following:
PSGI: What is it and what's the fuss about?
plack advent calendar: http://advent.plackperl.org/2009/12/day-1-getting-plack.html (buy the ebook if you can here: http://handbook.plackperl.org )
https://github.com/plack/Plack
Get some modern web-framerowk from CPAN - here are many (maybe too many) - the most known are:
Dancer (Dancer2)
Mojolicious
Poet/Mason
and of course, the big-gun: Catalyst
I personally mostly using
Poet/Mason
Mojolicious
EDIT
In your cgi-bin should exists a script called printenv.pl. Try:
chmod 755 printenv.pl
and point your browser to http://address/cgi-bin/printenv.pl You will get, the apache environment. See, you must know the basics of operating system commands and how the web works to succesfully run an web-application. It is impossible to write down everything in one answer, you need to use google, read answers to other questions here and such.
Also, in the above script, you can change the cat /etc/passwd to any other shell command for testing only what your cgi-script can or can not.
I've solved this problem by using plackup in combination of PSGI.
use CGI::Emulate::PSGI;
use CGI::Compile;
my $sub = CGI::Compile->compile("location/to/script.cgi");
my $app = CGI::Emulate::PSGI->handler($sub);
If you run plackup file.psgi, it sets up a local webserver that runs as the current user. Problem solved.
I have been using php for CGI scripting for some time now and recently got interested in lua.
I installed the latest version of luarocks(2.1.2) and the bundled version of lua(5.1.4). I wanted to start from the basics and hence installed cgilua(5.1.4-2) and all its dependencies using "luarocks install cgilua".
I am able to run simple lua scripts using the shebang line to point to my lua interpreter but when i use it to point to the cgi launcher "cgilua.cgi.exe" to run .lp files it just won't work. I edited my httpd configuration file to allow cgi execution in my htdocs and cgi-bin directory and used the cgi-script handler for .lp pages. I am trying to run the login.lp example in the cgilua examples directory. I even added the line "Content-type:text/html" to no avail. Executing the cgilua.cgi.exe file from the command line without arguments just closes the application with the message "cgilua.cgi.exe" stopped working".
Could anyone tell me what am I missing? Maybe the launcher is supposed to be used in a different way?
I don't suppose permissions have a part to play in this as in windows all users have at least read and execute permissions.
The url I'm trying to access is http://localhost/login.lp. My apache error log shows "Premature end of script headers: login.lp" with a 500 internal server error and the same thing if I access http://localhost/cgilua.cgi.exe
I don't know what your requirements are, but perhaps it will be easier to simply use apache's mod_lua.
http://httpd.apache.org/docs/trunk/mod/mod_lua.html
Warning: imagejpeg() [function.imagejpeg]: Unable to open '/home/SITENAME/public_html/files/cache/052f225905c1618003df0c5088aec7a9.jpg' for writing: Permission denied in /home/SITENAME/public_html/concrete/helpers/image.php on line 172
I emptied the cache directory and still no luck, and if I change the permissions on the cache folder then I get another error and I can't use the site at all:
Warning: require_once(Zend/Cache/Backend/File.php) [function.require-once]: failed to open stream: No such file or directory in /home/MYACCOUNT/public_html/concrete/libraries/3rdparty/Zend/Cache.php on line 133
Fatal error: require_once() [function.require]: Failed opening required 'Zend/Cache/Backend/File.php' (include_path='.:/usr/lib/php:/usr/local/lib/php:/home/owen/php') in /home/MYACCOUNT/public_html/concrete/libraries/3rdparty/Zend/Cache.php on line 133
I don't get it? I've never had this problem before.
Sounds like a permissions problem to me, but we can't tell from this end.
If you can FTP (or CD) into that /home/SITENAME/public_html/files/
and see if 'files' is owned by, and has the same permissions as public_html
Then see what permissions they NEED to have for your hosting setup.
Check that directory exists.
Check if web server daemon, most of the time - www-data, has write permissions to that particular directory.
For future reference the problem was the PHP handler. It has been changed to CGI mode (as opposed to DSO) and they turned suEXEC ‘off’ - might be useful for someone down the line.