AlternC

make mail_add dry by default to avoid potential catastrophe

remove verbosity on minute cronjob

don't pass the function as the login, it breaks deliver to -owner

fix delivery for virtual mailman this shouldn't affect regular usage, but was untested. basically, we don't want to go through horrible hoops to deliver mail to an alias, the mailman delivery script can handle it for us

print warning properly

V3.2.2 On se retrouve avec des écrans qui affichent avant et après la validation du formulaire de changement de mail avec des messages dont l'item ""help_mem_chgmail"" n'est pas traduit. Du coup, la procédure est pas compréhensible.

Fixing opendkim listening on *

do not use mysql_pconnect mysql_pconnect leaves stray mysql connexions lying around and we do our own connexion management anyways

depuis toujours, les vhosts d'alternc roulent sous le même user que le propriétaire des fichiers. avant, c'était "www-data" et on donnait les fichiers à "www-data", maintenant c'Est "gid" (où gid est l'identifiant numérique du compte AlternC, e.g. ... [More] "2000" pour "admin"). c'est mal. c'est tout aussi mal que de mettre les fichiers 666 ou 777 parce que, bien que ce n'est pas "tout le monde" qui peut écrire les fichiers, c'est le serveur web, qui est pas mal le seul user qui importe ici anyways. il est possible de permettre l'écriture de fichiers dans seulement certains répertoires (e.g. "files/" dans Drupal ou "wp-content/" dans Wordpress) afin de restreindre la portée d'une potentielle attaque, et la plupart des CMS contiennent des instructions spécifiques à ce sujet. j'ai passé 10 ans à expliquer comment AlternC était "spécial" à ce sujet car "tout est writable par défaut". la raison pourquoi Drupal (par exemple) permet l'écriture seulement dans "files/" n'est pas seulement cosmétique, pour garder les choses en ordre, mais aussi parce que Drupal inscrit un fichier .htaccess spécial dans ce dossier ("SetHandler? Drupal_Security_Do_Not_Remove_See_SA_2006_006\nOptions None\nOptions FollowSymLinks?") qui permet d'empêcher l'exécution de code PHP dans ce répertoire. depuis la mise à jour à AlternC 3.x, nous avons tout vu: des vhosts utilisés pour envoyer du spam avec des backdoors en php, des bouncers IRC en perl et en binaire, des sites de phishing droppés à des endroits plus ou moins arbitraires... même que nous avons vu une augmentation significative de ces attaques suite à la mise à jour, fort probablement à cause de la désactivation du safe mode. il devient donc urgent de régler ou au moins mitiger ce problème. l'approche que je suggère est de faire que, par défaut, le webserver ne peut pas écrire les fichiers, à moins qu'ils soient mis "a w" ou "g w" (préférable, mais les deux fonctionnent). donc on ferait: rouler les threads apache comme www-data:GID (au lieu de gid:gid) owership des fichiers: GID:GID (inchangé) permissions: 2750 (sticky group, writable par UID, readable/executable par GID, on enlève l'écriture au groupe) les ACLS permettent ensuite au alterncpanel d'écrire Pour tester ceci, j'ai créé ce vhost de notre côté: INSERT IGNORE INTO `domaines_type` (name, description, target, entry, compatibility, only_dns, need_dns, advanced, enable) values ('vhost-ro','Locally hosted (readonly)', 'DIRECTORY', '%SUB% IN A @@PUBLIC_IP@@', 'txt,defmx,defmx2,mx,mx2', false, false, false, 'ALL'); et ce template: <VirtualHost *:80> ServerName %%fqdn%% DocumentRoot "%%document_root%%" AssignUserId www-data #%%GID%% SetEnv LOGIN "www-data-%%LOGIN%%" <Directory "%%document_root%%"> php_admin_value open_basedir "%�count_root%%:/usr/share/php/:/var/alternc/tmp" php_admin_value upload_tmp_dir %�count_root%%/tmp php_admin_value sendmail_path '/usr/lib/alternc/sendmail "%%mail_account%%" ' Options MultiViews -FollowSymLinks SymLinksIfOwnerMatch AllowOverride AuthConfig FileInfo Limit Options Indexes </Directory> </VirtualHost> j'ai aussi dû patcher fixperms pour ne pas donner les permissions d'écriture au groupes: Index: fixperms.sh =================================================================== --- fixperms.sh (revision 5035) fixperms.sh (working copy) @@ -126,15 126,15 @@ # Set the file readable only for the AlternC User mkdir -p "$REP" chown -R $GID:$GID "$REP" - chmod 2770 -R "$REP" chmod 2750 -R "$REP" # # Delete existings ACL # # Set the defaults acl on all the files # setfacl -b -k -n -R -m d:g:alterncpanel:rwx -m d:u::rwx -m d:g::rwx -m d:u:$GID:rwx -m d:g:$GID:rwx -m d:o::--- -m d:mask:rwx\ # -Rm g:alterncpanel:rwx -m u:$GID:rwx -m g:$GID:rwx -m mask:rwx\ # "$REP" - setfacl -bknR -m d:u:alterncpanel:rwx -m d:g:alterncpanel:rwx -m u:alterncpanel:rwx -m g:alterncpanel:rwx -m d:o::--- -m o::---\ - -m d:u:$GID:rwx -m d:g:$GID:rwx -m u:$GID:rwx -m g:$GID:rwx -m d:mask:rwx -m mask:rwx "$REP" setfacl -bknR -m d:u:alterncpanel:rwx -m d:g:alterncpanel:r-x -m u:alterncpanel:rwx -m g:alterncpanel:r-x -m d:o::--- -m o::---\ -m d:u:$GID:rwx -m d:g:$GID:r-x -m u:$GID:rwx -m g:$GID:r-x -m d:mask:rwx -m mask:rwx "$REP" fixtmp $GID read GID LOGIN || true il resterait à permettre les CHMOD sur le FTP ainsi que sur le navigateur de fichiers pour que les gens puissent faire un chmod w. cette dernière partie sera particulièrement embêtante à cause du laborieux design de "fixperms.sh", qui remet joyeusement à zéro toutes ces permissions à des moments arbitraires. mais il faut certainement faire quelquechose. extrait de la première conversation que j'ai eu à ce sujet avec #alternc: 04:26:55 <@anarcat> pourquoi, grands dieux, on permet encore au serveur web d'ecrire dans les comptes? 04:27:02 <@anarcat> ca fait des spam runs a tout bout de champ ici 04:27:18 <@anarcat> on peut pas permettre aux gens de gerer leurs permissions comme il faut enfin? 04:34:09 <azerttyu> ?! 04:34:49 <@anarcat> azerttyu: ?!?&#*^!? 04:35:21 -!- FloTiX <[email protected]> has quit (Quit: ZNC - http://znc.in) 04:35:22 <fufroma_> anarcat: "serveur web écrire dans les compte" 04:35:23 <azerttyu> c'est à dire ? 04:35:26 <fufroma_> comprend pas 04:35:42 <fufroma_> que apache ai le droit de créer des fichiers ? 04:35:51 -!- cocoadaemon <[email protected]> has joined #alternc 04:35:52 -!- FloTiX <[email protected]> has joined #alternc 04:39:47 <@anarcat> oui 04:39:49 <@anarcat> c'Est ça 04:44:43 <fufroma_> et on explique aux gens qui ont des CMS qu'ils ne peuvent plus uploader d'images ? 04:45:56 <@anarcat> les gens sont capables de regler les permissions pour les CMS 04:46:10 <@anarcat> c'est documente, dans tous les CMS, comment faire pour changer ces permissions 04:46:31 <fufroma_> ouais, c'est documenter, ils disent de passer en 777 et de chown www-data 04:46:41 <fufroma_> 777 est une hérésie, et www-data est pas vrai dans le cas d'alternc 04:46:46 <@anarcat> ouais, par exemple 04:46:51 <@anarcat> boaf 04:47:03 <@anarcat> religion a part, presentement 777 ou pas, on se fait defoncer joyeusement ici 04:47:19 <fufroma_> des cms pas a jour ou d'autres raisons ? 04:47:25 <@anarcat> chown www-data est une heresie aussi, pourtant c'est exactement ce que alternc fait, et pas seulement pour files/ et settings.php 04:47:30 <@anarcat> des CMS pas a jour 04:47:46 <@anarcat> donc la au lieu de dire "vous avez pas d'images" on dit "on ferme ton compte ducon, parce qu'il est pas a jour" 04:47:54 <@anarcat> ca fait 2 fois cette semaines 04:47:57 <@anarcat> on a perdu un client 04:48:26 <fufroma_> ce qu'on a fait pour un client, c'est un template apache spécial joomla qui interdit l'execution de php dans tout les répertoire ou il n'est pas sensé y en avoir 04:48:26 <@anarcat> du coup ils ont pas d'images non plus hein 04:48:41 <fufroma_> ce qui fait que son joomla pas a jour se fait plus pirater 04:48:53 <fufroma_> (ya réguliérement des php pourri qui se font dé"poser, mais comme pas executable...) 04:48:58 <@anarcat> attends que le backdoor soit dans index.php, ca va etre rigolo 04:49:14 <@anarcat> on en voit de toutes les couleurs ici - des nouveaux fichiers, des backdoors dans les fichiers existants 04:49:19 <@anarcat> une telle mesure serait pas suffisante 04:49:27 <@anarcat> il faut que, par defaut, les fichiers soient pas writable par le serevur web 04:49:35 -!- FloTiX <[email protected]> has quit (Remote host closed the connection) 04:50:08 -!- FloTiX <[email protected]> has joined #alternc 04:50:38 <fufroma_> anarcat: ce que tu peux faire, c'est le faire "tout connement" via un template qui lance un script à la fin 04:50:44 <@anarcat> ca reglerait un autre FAQ WTF qu'on a souvent qui est "est-ce que vous pourriez mettre mes fichiers 777 svp?" 04:50:53 <@anarcat> fufroma_: faire quoi? 04:50:59 <fufroma_> tu te fait un type de domaine "site_read_only" et tu as juste a faire un script bash avec le bon nom 04:51:20 <fufroma_> quand le mec veux le remettre en read-write, il change de type de domaine dans son panel, fait sa vie, puis le repasse en read-only 04:51:27 <@anarcat> pas con 04:51:30 <@anarcat> m'enfin, il est 4h du mat ici et je veux dormir 04:51:35 <@anarcat> mais c'est une bonne piste 04:51:40 <@anarcat> a mon avis, ca devrait etre par defaut 04:51:51 <@anarcat> je serais curieux de savoir quoi mettre dans le vhost 04:51:58 <fufroma_> anarcat: https://alternc.org/wiki/UpdateDomainNextGen lit le morceau "Exemple d'ajouts de fonctionnalités" 04:52:18 <fufroma_> ca explique comment lancer un script bash automagiquement à la création d'un domaine 04:52:34 <fufroma_> sinon, l'autre solution, c'est avoir un utilisateur virtuel pour apache qui a les droits que en RO 04:52:53 <fufroma_> et quand tu choisi le type de domaine, ca met comme AssignUserId cet utilisateur, qui pourra pas écrire 04:53:08 <fufroma_> cette solution et meme plus élégante dans un sens, ca demande pas de toucher aux fichiers lors du changement 04:53:23 <fufroma_> et avec le nouvel update_domain de alternc 3.3 la regénération apache est instantanné 04:53:33 -!- WhilelM <[email protected]> has quit (Ping timeout: 266 seconds) 04:53:33 -!- domi_ <[email protected]> has quit (Ping timeout: 266 seconds) 04:53:39 <fufroma_> ca demande juste a modifier le fix_perms pour rajouter un utilisateur qui aurait des droits que en RO 04:54:18 <@anarcat> ack 04:54:18 -!- domi_ <[email protected]> has joined #alternc 04:54:26 <@anarcat> faudrait avoir un user par compte dans ce cas-la aussi? 04:54:33 -!- WhilelM <[email protected]> has joined #alternc 04:55:08 <fufroma_> un user global suffirait je pense 04:55:18 <fufroma_> ya l'openbasedir pour pas qu'il "balade" 04:55:18 <@anarcat> ca pourrait pas simplement etre "www-data"? :p 04:55:41 <@anarcat> pcq je pensais que le but de itk, c'etait justement qu'on se fie pas sur l'openbasedir 04:55:50 <fufroma_> itk ca compléte 04:56:00 <@anarcat> pff 04:56:01 <@anarcat> d'accord 04:56:04 <fufroma_> itk ca empeche pas d'aller dans /etc/ si ton user a les droits 04:56:06 <@anarcat> merci du feedback 04:56:23 <@anarcat> pourquoi tu donnerais les droits aux users d'aller dans /etc je te demande 04:57:01 <@anarcat> enfin 04:57:02 <@anarcat> merci 04:57:09 <@anarcat> bonne nuit, pour ce qui en reste ici [Less]

fix error handling in do_actions.php