[opensuse] Perl cgi script user and write permission in htdocs
I have a script that, when the user asks for it (by pressing a button on a form on which there is nothing else), reads data from my database, based on the identity of the user that initiated the request, constructs a PDF from the data, and stores the pdf in a subdirectory ('misc') of htdocs. I have followed the practice recommended by Apache of not making htdocs itself writeable by my scripts. After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Because of the number of such PDFs, they are organised into subdirectories (four digit year) and sub-sub-directories (two digit month). NB: This script works fine on any flavour of Windows (though some may argue about the security, or lack thereof, on Windows, in allowing cgi scripts write data to htdocs). In any event, what happens is that on my OpenSuse Linux box, the script in question dies the moment it tries to create the target subdirectory, complaining that permission is denied. For the perl programmers reading this, I am using the function 'mkpath' in the Perl package 'File::Path'. What magical incantation do I need to invoke to have this script working on my Suse box? I am asking here because I believe it is a problem with permissions on /srv/www/htdocs/misc and that it is not a programming problem per se. I did try googling, and tried the 'solutions' I found in that search, but none of the 'solutions' worked (what I give at the beginning of this note is one of those 'solutions'. Any aide would be appreciated. Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created.
Is Apache running as www, or is it running as "nobody"? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi John, On 14-02-06 03:23 PM, John Andersen wrote:
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Is Apache running as www, or is it running as "nobody"?
In uid.conf, I see the User is set to wwwrun and the Group is www. I would assume, then, that it is running as wwwrun. Is that correct, or does that reveal my ignorance of the linux world. ;-) Does the owner and group assigned to the cgi scripts matter? They are all set to root/root, I assume because I had to sudo cp them from my working directory to /srv/www/cgi-bin. I would assume (hope) that they're executed as whatever user Apache runs as, though, and that the ownership affects only the ability to edit them, because it would be really bad if they ran as root (though it seems to be mostly working, and this machine is a workstation that is not accessible to the outside world). If that is wrong, then tell me how to fix that. Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2/6/2014 12:34 PM, Ted Byers wrote:
Hi John,
On 14-02-06 03:23 PM, John Andersen wrote:
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Is Apache running as www, or is it running as "nobody"?
In uid.conf, I see the User is set to wwwrun and the Group is www. I would assume, then, that it is running as wwwrun. Is that correct, or does that reveal my ignorance of the linux world. ;-)
Well (off the top of my head): if user wwwrun is a member of www, then it restricted to the group permission in that directory, which in your case is read execute. You need to write in that subdirectory (to create a subdirectory or a file). So it would EITHER need to OWN /srv/www/htdocs/misc, or the Group www would need write authority to that directory. (775) Someone more accustomed to managing web servers than I could probably recommend best practices.
Does the owner and group assigned to the cgi scripts matter? They are all set to root/root, I assume because I had to sudo cp them from my working directory to /srv/www/cgi-bin. I would assume (hope) that they're executed as whatever user Apache runs as, though, and that the ownership affects only the ability to edit them, because it would be really bad if they ran as root (though it seems to be mostly working, and this machine is a workstation that is not accessible to the outside world). If that is wrong, then tell me how to fix that.
Thanks
Ted
I'm not an expert of this, just going by the symptoms you posted. Presumably your cgi scripts are executable by wwwrun (or anyone), (and not suid root). but as long as you can execute them as wwwrun that should work, and they should run as the userid that invoked them. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi John, Thanks, On 14-02-06 03:49 PM, John Andersen wrote:
On 2/6/2014 12:34 PM, Ted Byers wrote:
Hi John,
On 14-02-06 03:23 PM, John Andersen wrote:
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Is Apache running as www, or is it running as "nobody"?
In uid.conf, I see the User is set to wwwrun and the Group is www. I would assume, then, that it is running as wwwrun. Is that correct, or does that reveal my ignorance of the linux world. ;-) Well (off the top of my head): if user wwwrun is a member of www, then it restricted to the group permission in that directory, which in your case is read execute.
You need to write in that subdirectory (to create a subdirectory or a file). So it would EITHER need to OWN /srv/www/htdocs/misc, or the Group www would need write authority to that directory. (775) Thanks. Using chmod 775 addressed the proximate problem.
Someone more accustomed to managing web servers than I could probably recommend best practices.
While my immediate problem is solved, I eagerly await advice on best practices.
Does the owner and group assigned to the cgi scripts matter? They are all set to root/root, I assume because I had to sudo cp them from my working directory to /srv/www/cgi-bin. I would assume (hope) that they're executed as whatever user Apache runs as, though, and that the ownership affects only the ability to edit them, because it would be really bad if they ran as root (though it seems to be mostly working, and this machine is a workstation that is not accessible to the outside world). If that is wrong, then tell me how to fix that.
Thanks
Ted I'm not an expert of this, just going by the symptoms you posted.
Presumably your cgi scripts are executable by wwwrun (or anyone), (and not suid root). but as long as you can execute them as wwwrun that should work, and they should run as the userid that invoked them.
If they did suid root, that can only be by evil magic in the behaviour of the web server that I haven't read about, as I would never do such a thing (deliberately) within my code. As a couple colleagues have had their servers hacked, I have been increasingly paranoid about writing my code in such a manner as to make my web app that is hard to hack. Thanks again, Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/06/14 21:49, John Andersen wrote:
On 2/6/2014 12:34 PM, Ted Byers wrote:
Hi John,
On 14-02-06 03:23 PM, John Andersen wrote:
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Is Apache running as www, or is it running as "nobody"?
In uid.conf, I see the User is set to wwwrun and the Group is www. I would assume, then, that it is running as wwwrun. Is that correct, or does that reveal my ignorance of the linux world. ;-)
Well (off the top of my head): if user wwwrun is a member of www, then it restricted to the group permission in that directory, which in your case is read execute.
You need to write in that subdirectory (to create a subdirectory or a file). So it would EITHER need to OWN /srv/www/htdocs/misc, or the Group www would need write authority to that directory. (775)
Someone more accustomed to managing web servers than I could probably recommend best practices.
As usual, the answer is: It depends. If the cache directory is only used by the CGI script, it should be owned by wwwrun. Make sure that the directory is cleaned up regularly, e.g. by a cron job. If that directory with PDF files is used by another process, too, or if sysadmins need write access to it, than group write access is the better way to go. (Or ACLs, if one is not able to tune group ownership fine-grained enough.) Actually, best practice would be to not create such an intermediate file directory directly accessible by Apache at all, but serve the PDF file from the script. If a cache directory is necessary, it should be somewhere else, not under /srv/www/htdocs/; still owned by wwwrun. Or, for larger and more professional demands, one would use an application server that creates and delivers the PDF documents. (Our Web applications generate, format, and deliver millions of individualized documents per year on each installation; PDFs created dynamically by TeX & friends.) Best, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/06/14 21:49, John Andersen wrote:
On 2/6/2014 12:34 PM, Ted Byers wrote:
Hi John,
On 14-02-06 03:23 PM, John Andersen wrote:
On 2/6/2014 12:01 PM, Ted Byers wrote:
After creating /srv/www/htdocs/misc, I applied 'chrgp www /srv/www/htdocs/misc' and 'chmod 755 /srv/www/htdocs/misc'. I do not know if there is a better option. But what is critical is that Apache can serve the PDF my script has created. Is Apache running as www, or is it running as "nobody"?
In uid.conf, I see the User is set to wwwrun and the Group is www. I would assume, then, that it is running as wwwrun. Is that correct, or does that reveal my ignorance of the linux world. ;-) Well (off the top of my head): if user wwwrun is a member of www, then it restricted to the group permission in that directory, which in your case is read execute.
You need to write in that subdirectory (to create a subdirectory or a file). So it would EITHER need to OWN /srv/www/htdocs/misc, or the Group www would need write authority to that directory. (775)
Someone more accustomed to managing web servers than I could probably recommend best practices. As usual, the answer is: It depends.
If the cache directory is only used by the CGI script, it should be owned by wwwrun. Make sure that the directory is cleaned up regularly, e.g. by a cron job.
If that directory with PDF files is used by another process, too, or if sysadmins need write access to it, than group write access is the better way to go. (Or ACLs, if one is not able to tune group ownership fine-grained enough.) Actually, the directory in question is intended to be more than a cache. The contents are intended to be permanent, once created, and never change. And they are connected to a specific entity, and
Hi Joachim, See below: On 14-02-06 05:21 PM, Joachim Schrod wrote: therefore a subset of the users connected to that entity (owner or selected employees), are authorized to see them after, and only after, they have been created. Only the script in question is ever to write data to that directory. And indeed, only that script creates the web page that gives users access to these files (that is, it checks to see if the file(s) exist, and if so, creates a web page that provides the URLs to get the files. And if they do not exist, and if and only if the user has authorization to create the files, it creates them and then gives the web page that provides the links to access them. If the user is not authorized to create these files, they see only an executive summary, and the button that launches this script is not put on the executive summary page, so that user has no way to even look for the files (I have created a sophisticated permissions system that dynamically carefully controls what each user is able to see and do).
Actually, best practice would be to not create such an intermediate file directory directly accessible by Apache at all, but serve the PDF file from the script. If a cache directory is necessary, it should be somewhere else, not under /srv/www/htdocs/; still owned by wwwrun. Or, for larger and more professional demands, one would use an application server that creates and delivers the PDF documents. (Our Web applications generate, format, and deliver millions of individualized documents per year on each installation; PDFs created dynamically by TeX & friends.)
Best, Joachim
This is actually a relatively simple script. I have a more demanding one involving a script that allows an authorized user to download a substantial amount of data in a CSV file. The quantity of data, though,m can be such that I have to have the database write the data directly to a file which is then read by my script and served to the user. Thus, I need, somehow, to set up a directory to which MySQL (and where would I find out what user mysql runs as) can write and wwwrun can read. BTW: I realize this is a newby question, but all the documentation I have read for chown refers only to files. Does it work on directories also, or is the another command I need to look up? Thanks Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/06/14 23:57, Ted Byers wrote:
Thus, I need, somehow, to set up a directory to which MySQL can write and wwwrun can read.
Really mysql? The database server writes the file? Well, in that case I would advise to add the user mysql to group www and make that directory group writable: groupadd --add-user mysql www chgrp --recursive www /srv/www/htdocs/misc chmod g+ws www /srv/www/htdocs/misc The last command asserts that newly created files in that directory belong to group www as well, so that wwwrun can read them. Btw, are you sure that the group's named www? By default, on openSUSE wwwrun's group is named wwwrun, too. Concerning your question:
(and where would I find out what user mysql runs as)
Interesting question; that's not as easy. ps -ef lists all running process. The first column lists the account name that owns the process. One can filter ps' result with grep. I.e.: puma:data-dictionary $ ps -ef | grep mysql root 16332 1 0 01:24 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --datadir=/data/mysql mysql 16682 16332 0 01:24 ? 00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/data/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysql/mysqld.log --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --port=3306 schrod 16774 2621 0 01:25 pts/2 00:00:00 grep mysql (Probably the lines will have been wrapped around; there are three lines as the command result.) -- The last line lists our grep command, we can ignore it. -- The 1st line is about a command /bin/sh with parameters /usr/bin/mysqld_safe and more args, process owned by root. -- The 2nd line is about a command /usr/sbin/mysqld, process owned by account "mysql". You'll have to deduce from the command names that the 2nd line is the actual server process, and the 1st line is the sysadmin command that starts the server. (There are more clues about that, but I don't have the energy to write them up at 1h30 am... ;-))
BTW: I realize this is a newby question, but all the documentation I have read for chown refers only to files. Does it work on directories also, or is the another command I need to look up?
Yes, both chown and chgrp also work on directories. If the directory has files in it and you want to change owner/group of these files as well in one go, you can use the option --recursive, as quoted above. Actually, it's quite an interesting question if file manager GUIs like KDE's Dolphin etc. support some of these actions (change ownership and group, access modes, also recursively) good enough for a newbie like you who comes from a Windows background to be a better environment than shell commands. I cannot really tell that, as I don't use these file managers. HTH, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ted Byers wrote:
Only the script in question is ever to write data to that directory. And indeed, only that script creates the web page that gives users access to these files (that is, it checks to see if the file(s) exist, and if so, creates a web page that provides the URLs to get the files. And if they do not exist, and if and only if the user has authorization to create the files, it creates them and then gives the web page that provides the links to access them. If the user is not authorized to create these files, they see only an executive summary, and the button that launches this script is not put on the executive summary page, so that user has no way to even look for the files (I have created a sophisticated permissions system that dynamically carefully controls what each user is able to see and do).
What stops the user simply typing in the URL of a PDF document? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ted Byers wrote:
Only the script in question is ever to write data to that directory. And indeed, only that script creates the web page that gives users access to these files (that is, it checks to see if the file(s) exist, and if so, creates a web page that provides the URLs to get the files. And if they do not exist, and if and only if the user has authorization to create the files, it creates them and then gives the web page that provides the links to access them. If the user is not authorized to create these files, they see only an executive summary, and the button that launches this script is not put on the executive summary page, so that user has no way to even look for the files (I have created a sophisticated permissions system that dynamically carefully controls what each user is able to see and do). What stops the user simply typing in the URL of a PDF document? Very little. But our user base is, at best, cognitively challenged, and, to enter the URL they'd have to see it, and either write it down or remember it. I know, security through obscurity is not generally adequate, but in this case, what they'd need to do is beyond all of
On 14-02-07 05:59 AM, Dave Howorth wrote: them, and, even if one of them did manage it, there is no harm that they could do by doing so. (In some organizations, it would be asked why one would bother to secure them at all.) It was decided, not by me, that the cost of strengthening the security of these documents is many orders of magnitude greater than the risks in not providing greater security for these documents, and so I was asked to focus on other things. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Dave Howorth -
Joachim Schrod -
John Andersen -
Ted Byers