[RCD] Update 0.9.1 released

Reindl Harald h.reindl at thelounge.net
Tue May 21 11:26:19 CEST 2013

Am 21.05.2013 11:11, schrieb A.L.E.C:
> Ok, this one was only for default PHP config. I'm not saying that
> PHP session is less secure in general.

and you take away any serious option from admins not using
default php configs at all since decades because they
know what they are doing

> but can you imagine two http servers using the same session (on another
> machine)? or one http server using two db servers?

but you can imagine that such things are not the general
usage and optimizing for this should be optional?

hence if a admin thinks he needs seperated session
storage he would do something like below and for
custom session-handlers and integration of memcache
"auto_prepend_file" was invited

<Directory "/usr/share/roundcubemail">
 php_admin_value session.gc_probability "1"
 php_admin_value session.gc_divisor     "100"
 php_admin_value session.gc_maxlifetime "7200"
 php_admin_value session.save_path       "/var/www/sessiondata-rc"

>>> - no session file locking (parallel requests do not wait)
>> and no integrity and cleanups or how do you explain me the
>> 5000 records in the session table on a server with a few
>> users after some months?
> Roundcube uses PHP's session garbage collector. If you disabled it then
> it's your problem to clean old sessions. It of course might be a bug

well, that happens if application developers choose to ignore
the well thought configuration as default, hence that is why
using a customized session handler should be *optional*

if you mangle session management outside the admins scope
do it really including garbage collection or make the
custom handler *optional*

this way a sane session configuration looks like for
some hundret domains with webapps:

every 10 minutes: find /var/www/sessiondata -type f -mmin +30 -delete
this happens in a cronjob and takes away the burden of session
cleanup from the webserver and if you ever had 20000 session files
you know why, this combined with /var/www/sessiondata as large
enough tmpfs will outperform your mysql-sessionhandler by not
produce any disk-IO for session management at all

this survives DDOS-attacks, been there, done that

session.save_path                         = "/var/www/sessiondata"
session.save_handler                      = "files"
session.use_cookies                       = 1
session.use_only_cookies                  = 1
session.name                              = "SESSION_ID"
session.referer_check                     = ""
session.auto_start                        = 0
session.cookie_lifetime                   = 0
session.cookie_path                       = "/"
session.cookie_domain                     = ""
session.cookie_secure                     = 0
session.cookie_httponly                   = 1
session.serialize_handler                 = "php"
session.gc_probability                    = 0
session.gc_divisor                        = 50000
session.gc_maxlifetime                    = 1800
session.entropy_file                      = "/dev/urandom"
session.entropy_length                    = 32
session.cache_limiter                     = "nocache"
session.cache_expire                      = 180
session.use_trans_sid                     = 0
session.bug_compat_42                     = 0
session.bug_compat_warn                   = 0
session.hash_function                     = 1
session.hash_bits_per_character           = 6
url_rewriter.tags                         = "disabled"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.roundcube.net/pipermail/dev/attachments/20130521/6d7439f1/attachment.sig>

More information about the dev mailing list