Droit d’accès, group, ACL ... je suis perdu

Support Debian
#1

Bonjour,

Je suis actuellement entrain de faire un peut de ménage et de revoir quelque configuration d’un serveur Debian.

Pour décrire la situation actuel, sur le serveur l’ont retrouve une api ( symfony, php-fpm 7.2 )
Le front en VueJs qui a juste besoin d’apache … ( donc api + front sous www-data )
Quelque micro-service en Nodejs ( qui tourne sous www-data aussi :confused: )
Un serveur FTP. ( qui a sont propre utilisateur )

Dans l’optique de rajouter un poils de securiter et organisé le tout un peut mieux …
J’aimerais pouvoir garder l’api et le front qui ont besoin d’apache sous le compte www-data …
Avoir un utilisateur special pour tout les micro-service Nodejs
Garder mon utilisateur ftp

Mon soucie est au niveau des droit d’access sur les fichier.
L’utilisateur FTP upload des fichier dans un dossier de l’api …
Celle-ci doit pouvoir les lire/modifier/supprimer
( A ce niveau la, sa fonctionne , mais je ne sais pas qu’elle configuration a était faite pour :confused:

un getfacl dans le dossier en question retourne :

# file: .
# owner: www-data
# group: www-data
# flags: -s-
user::rwx
user:www-data:rwx
user:energysolution:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:energysolution:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

)

Et mes micro-service qui tourneront sous un autre utilisateur devront eux aussi pouvoir crée/modifier/supprimer des fichier dans un dossier de l’api :confused:

Je ne sais pas comment faire ça :confused:

#2

Ha les droits !
J’ai tenté ACL, j’y ai cru parmis tant d’autres, mais non. Ma solution personnelle a été le pool php-fpm.

#3

Pour un peu de précision car je gere un serveur web aussi :
Le CDR que je me suis imposé, etait de remplacer ISPConfig 3.1 par un truc plus solide en securité et aussi plus recent dans ses versions PHP.

  • Connexion uniquement en SFTP par certificat pour les users (donc des clients)
  • Chroot SSH dans leur home respectives avec un ou plusieurs sites (natif sshd.conf)
  • Les clients sont proprios et Apache doit faire ce qu’il veut

Donc j’ai eu un peu prêt le même soucis que toi, car pour écraser un fichier en FTP ou SFTP, il te faut nécessairement des droits élevés qui sortent du cadre standard des groupes lorsqu’Apache est proprio et qui doivent être en chmod 755/644 en meme temps (dossier/fichier, ce qui n’est pas ton cas actuel).

Le pool php-fpm rentre parfaitement dans mon cas de figure, je te laisse a la documentation si je vois juste :wink:

[edit HS] Aussi, après avoir lu et participer a ta précédente question, il me semble qu’un membre t’avait suggéré BindFS qui peut aussi te rendre service après avoir bougé ton /www dans /home. Je suis plutôt d’accord si cela reste provisoire, mais c’est une piste a creuser te concernant. Je peux être plus précis, si tu en a besoin, n’hésites pas.

Suite de l’aventure dans les droits :

#4

Merci pour ta réponse.

J’utilise déjà php-fpm, mais plus pour une notion d’optimisation de l’utilisation des ressources …
Notre solution souffre encore de quelque problème d’optimisation, il y a beaucoup de calcul mathématique et les jeux de donner dépasse la limite du raisonnable …

Pour le moment la partie FTP ne va pas poser de problème puisqu’elle fonctionne correctement, et suite a une réunion ce matin nous avant pris la décision de les remplacer afin d’unifier le parc et de tout avoir par email :wink:
Mais n’empêche que la configuration du dossier m’intéresse ^^

Pour ce qui est de BindFS, la solution était bonne, mais je n’ai pas trop de problème avec la configuration d’apache et les vhost… je préfère les faire moi-même.

C’est un peu ce que je me suis dit sur mes premiers tests …
Mais je pense vraiment (peut être a tort) que c’est LA solution …
Donc je vais faire comme a l’époque ou j’ai appris à lire et écrire des Regex …
je me tire une balle dans le pied, je sers les dents et je sors le kit de suture …

Bon après j’ai toujours l’option d’aller modifier les micro-services pour qu’il fasse un chown www-data sur les fichiers a la fin de leur traitement, mais cette solution ne sera pas portable :confused:

Des liens vers un kit de suture sur les ACL :crazy_face: ?

#5

Pour l’avoir tenté, je te dis de suite que tu vas te casser les dents si tu veux des droits standardisés (755/644), il te faudra toujours les elever pour que le groupe puisse écrire, même si tu mets l’user en groupe proprio, me demande pas pourquoi; j’ai donc trouvé ACL inutile dans mon cas et la config que tu donnes résume et confirme, a priori, bien ce que je dis.

Hors, si tu utilises php-fpm, tu dois bien déclarer son pool dans le VHost du domaine. Et il y a simplement une petite conf a réaliser dans ce pool pour solutionner ton problème en déclarant l’user qui fait du FTP. Ça n’impactera aucunement Apache et donc les outils qui en ont besoin.

#6

Comment ça ?

Tu fais tourné apache sous www-data et ton pool fpm par l’utilisateur a qui appartiens le dossier O_o ?

Mon but etant, justement avoir un utilisateur différent pour ce qui est accessible/exécuter depuis le web ( donc mon api en php ) et pour mes micro-service interne …

J’ai l’impression que ta solution reviens au même par rapport a ce qui tourne maintenant ( tous sous www-data )

Gère les droit avec “les droits stanfardisés” ne corrige pas mon problème.
le xx7 donne access au “autres” … ou autrement dit : tous le monde !
Enfin le but n’est de tout avoir en 777 et de collé un post-it avec le mdp root sur le serveur … ^^

Je pense théoriquement pouvoir m’en sortir avec un simple groupe linux mais je n’ai pas assez de connaissance dans la gestion des utilisateur de linux :confused:

#7

Tu te poses exactement les mêmes questions que moi il y a un mois et dont je t’ai collé les threads plus haut.
En effet :

OUI

#8

???

(PS je suis entrain lire les post :wink: )

#9

Ben disons que je suis plus attaché que toi sur l’aspect sécurité. Sans être un extraordinaire sysadmin qui pourraient te donner les tenants et aboutissants avec des explications très précises, je part d’un constat simple qui est que sur n’importe quelle plateforme, que se soit ISPConfig ou un petit hébergeur mutualisé et partout ailleurs, les droits sont standardisés en 755/644 lorsqu’il sagit de “web” et c’est en fouillant comment c’etait fichu sur ISP que j’ai découvert FPM dans cet usage.
En gros, je ne sais pas t’expliquer comment un hacker ferait pour exploiter un dossier en 770 et un fichier en 664, tout ce que je sais en temps que webmestre qui utilise bcp de CMS, c’est que ces dit CMS (wp, prestashop) vont t’afficher un placard te rappelant cet aspect sécurité si les droit sur les dossiers/fichiers ne sont pas bons et donc je ne peux pas me permettre de livrer ça a un client :slight_smile:

#10

Tu as surement plus de reculs et de connaissance que moi sur le sujet, je n’en doute pas, si non je serai pas la …
mais j’aime bien comprendre comment cela fonctionne vraiment …

Après ce qui est sécurité au niveau des CMS, la gestion de droit ne fais pas tout …
Si tu prends par exemple la configuration “apache” des serveurs mutualisé OVH, du moment qu’un fichier comporte .php sans son nom, il passera par l’interpréteur PHP.
(Ce qui est pour moi une énorme faille, déjà signalé, mais d’après eux c’est normal …).

Si ton php derrière n’est pas bien configuré, rien ne t’empêche d’envoyer une fausse image ( img.php.jpeg)(en plus le type mime est tellement simple a bypasse que les cms n’y voie que du feu) avec du code dedans pour changer les droits sur un fichier et demander au serveur un café …

Faire tourner la pool php sous un autre utilisateur me semble pas un choix judicieux. Enfin pas utile dans mon cas puisque qu’au final j’ai seulement 2 utilisateurs ( www-data et mon utilisateur pour Nodejs ) …
(je n’aie pas cette notion d’utilisateur dynamique, scalable, dans un environnement d’hébergement …)

Apparemment de ce que j’ai compris de t’es autre thread tu t’en es sortie surtout grâce au chroot qui permet d’isoler t’es utilisateur ftp.

Par contre je suis certainement un peu débile ^^ mais j’ai besoin de me prendre le mur en pleine tête pour confirmer son existence.
Je vais donc voir si je m’en sors avec les ACL…

Et avec toutes les infos que tu ma donnée j’ai au moins une solution de backup pour le moment je me serais arracher tous les cheveux ^^
Encore merci :wink:

#11

Le chroot est un plus. Mon serveur contient 2 sites qui sont les miens et qui ne sont donc pas soumis au même limitations que mes clients; mon user (fred) est un sudoer qui a /home/fred/site1 et /home/fred/site2 comme mes clients. La seul différence est que je ne suis pas confiné et donc FPM s’en fiche royal.
Par contre, j’peux pas aller chez client1 faire des modifs en SFTP si je suis log en fred car je ne suis pas proprio :wink: <= C’est sur ce point qu’il est intéressant de distinguer apache des proprios a mon humble avis, ce qui etait le cas avec fe BindFS lors de mes tests.