Upload dir permissions

[Ed Pigg]

Hi all,
I'm trying to setup a system where users can upload images to a 
designated uploads dir. Once the file is successfully uploaded I want 
to transfer it to an image directory with a filename I have assigned. I 
can do those things with by current application. I needed to change the 
permissions of the upload dir to world writable in order for this to 
work. I'm not exposing the development system to the internet, so I can 
do this now while testing the application, however I want to make sure 
that I'm not exposing the upload dir or final image dir to mischief.

Do I need to make the webuser part of a group that will have write 
access to the dir's? What are the best practices for this type of 
thing.

Thanks
Ed
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Upload dir permissions

[Ed Pigg]

On Nov 19, 2004, at 12:10 PM, Chasecreek Systemhouse wrote:
On Fri, 19 Nov 2004 11:50:41 -0600, Ed Pigg <[EMAIL PROTECTED]> 
wrote:
I'm trying to setup a system where users can upload images to a
designated uploads dir. Once the file is successfully uploaded I want
Keep account creation and uploads separate functions.
In this case the user will not have a separate site or account. 
Appropriate authenticated users will be able to upload images.


Do I need to make the webuser part of a group that will have write
access to the dir's? What are the best practices for this type of
thing.
Yes; here is soemthing to get you started -- change server/directpry
references as approppriate:
Thank you for the example.
I am able to upload the image file already. That part I have figured 
out. What I'm more concerned about is setting appropriate permissions 
on the upload dir, so that the web application can write to it but not 
so much that I'm needlessly exposing the directory to the outside 
world. I want to open the door just enough to get the job done by the 
web application and no more. Is that clear? It's not strictly a Perl 
question unless I need to get the application to change.

I want to make sure that I am taking the site security seriously and 
don't expose it to threats needlessly.

Thanks
Ed
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Upload dir permissions

[Ed Pigg]

On Nov 19, 2004, at 12:37 PM, Chasecreek Systemhouse wrote:
On Fri, 19 Nov 2004 12:29:21 -0600, Ed Pigg <[EMAIL PROTECTED]> 
wrote:

I want to make sure that I am taking the site security seriously and
don't expose it to threats needlessly.
=)  You have taken a step into a largewr world.  Welcome  =)
Thanks. As always, it is not a matter of whether or not the task can be 
done, it's whether or not it can be done in a secure manner. I'll check 
out the W3 Security FAQ's.

Ed
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Passing Perl parameters in a cgi-script

[Ed Pigg]

On Feb 21, 2006, at 1:08 AM, Mary Anderson wrote:



I have come to the conclusion that passing perl parameters from one  
perl
subroutine to another just doesn't work in CGI.  It looks like  
everything

is passed by value, and the language is not set up to take refs.  This
being the case, how best to handle the following piece of DBI code:

my$dbh = DBI:connect($connectionString);   # connect to the  
database

my$sth = $dbh->prepare($cmd);   # prepare a command



Using my declares the listed variables to be local (lexically) the  
variable to the enclosing block, file, or "eval".

perldoc -f my

References can be passed.
perldoc perlref
perldoc perlreftut


What I think that I have found is that

my $dbh = DBI:connect($connectionString)  # dbh is a global  
variable set

in a global context


I am going to assume that you do this at the beginning of your cgi  
script. You would now have a database handle to use for the remainder  
of the script.




..

sub fubar{
  my $sth = $dbh->prepare($cmd);
}
seems to work, but it does not work to have the global variable set  
inside
a subroutine and accessed from another.  If it were a character  
string, I
would use hidden() to pass the values from one subroutine to  
another, but

the cgi macros are not set up to handle ref variables!


It sounds like you are trying to pass the handle to a separate  
request to the server. Since it is scoped to the first script you  
can't do that. You can transfer values in hidden fields of a form or  
in a session that can be accessed by the next process. There are ways  
to handle persistent database connections, although I have not worked  
with them at this point. If I know I will need a handle I grab it at  
the beginning of the script and then close it when I am done.




If I am right, that I can set $dbh globally and access it from some
subroutine, can I do this

if (something is true) {

my   $dbh = DBI:connect($connectionString);
}


That will get you a database handle that is valid inside the  
(something is true) block.


sub fubar{
my $sth = $dbh->prepare($cmd)



$dbh does not exist inside the fubar block.

Ed Pigg

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>