phpgroupware-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Phpgroupware-cvs] CVS: phpgwapi/doc SECURITY,1.2,1.3


From: Miles Lott <address@hidden>
Subject: [Phpgroupware-cvs] CVS: phpgwapi/doc SECURITY,1.2,1.3
Date: Sun, 12 May 2002 11:07:37 -0400

Update of /cvsroot/phpgroupware/phpgwapi/doc
In directory subversions:/tmp/cvs-serv25246

Modified Files:
        SECURITY 
Log Message:
spelchek

Index: SECURITY
===================================================================
RCS file: /cvsroot/phpgroupware/phpgwapi/doc/SECURITY,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -r1.2 -r1.3
*** SECURITY    24 Sep 2001 22:16:13 -0000      1.2
--- SECURITY    12 May 2002 15:07:34 -0000      1.3
***************
*** 1,25 ****
! First off, I would not recommend using this in a type of enviroment that 
  security is a really big concern.  I am *NOT* saying that you shouldn't be
! concerned about it, but, until the system is thoughly tested.  I would not
  recommend it.
  
! Because of the current methods that the email system works.  It is required
  that the users password is in the sessions table.  IMAP needs the password
  to verify the user.  This is one of the main reasons for the stalesessions
! program.  I do not like keeping passwords in any medium that is not encryped.
  
! The email system stores its file attachments in a temp directory.  For right
! now, you need to watch this directory because it can fill up very quickly.
! If a user does not finsh composing the message (going else where in the 
program, 
! internet connection dieing, browser crash, etc) the file will sit there until
  it is deleted.  There will be a simple cron program to go through and clean
  things up.  
  
  The files/users and files/groups directories need to be writable by the UID
! that php runs under (nobody or your apache UID). This is a security risk
  if 3rd parties can place php or cgi scripts on your machine, because they
  will have full read/write access to those directories.
  You should also consider moving the files directory outside of the
! tree your webserver has access to to prevent websurfers from directly 
accessing
  the files, or add in .htaccess files to restrict access to that tree.
  
--- 1,25 ----
! First off, I would not recommend using this in any type of environment in 
which
  security is a really big concern.  I am *NOT* saying that you shouldn't be
! concerned about it.  But, until the system is thoroughly tested, I would not
  recommend it.
  
! Because of the current methods that the email system uses, it is required
  that the users password is in the sessions table.  IMAP needs the password
  to verify the user.  This is one of the main reasons for the stalesessions
! program.  I do not like keeping passwords in any medium that is not encrypted.
  
! The email system stores its file attachments in a temp directory.  For now,
! you need to watch this directory because it can fill up very quickly.
! If a user does not finish composing the message (going else where in the 
program, 
! Internet connection dieing, browser crash, etc) the file will sit there until
  it is deleted.  There will be a simple cron program to go through and clean
  things up.  
  
  The files/users and files/groups directories need to be writable by the UID
! that php runs under (nobody or your apache UID).  This is a security risk
  if 3rd parties can place php or cgi scripts on your machine, because they
  will have full read/write access to those directories.
  You should also consider moving the files directory outside of the
! tree your web server has access to to prevent web surfers from directly 
accessing
  the files, or add in .htaccess files to restrict access to that tree.
  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]