Distribution EOLE » Modules » Scribe » EOP

Comportement semblable depuis les deux interfaces ead2 et eop.

Semblable jusqu’à un certain point (premier fichier généré via eop, second via ead2) :

getfacl : suppression du premier « / » des noms de chemins absolus
# file: home/p/prof1/perso/mot-de-passe_24_10_0.csv
# owner: root
# group: root
user::rw-
user:prof1:rwx                  #effective:rw-
group::---
mask::rw-
other::---

# file: home/p/prof1/perso/mot-de-passe_24_10.csv
# owner: root
# group: root
user::rw-
user:prof1:rw-
group::---
mask::rw-
other::---

Les deux interfaces ajoutent l’acl requise pour donner accès à l’utilisateur en lecture et écriture.

Dans le cas de l’EAD2, il y a un ajout explicite de l’acl dans le code de l’action de l’EAD.

Dans le cas de eop, il semble que l’attribution de l’acl soit uniquement dû à l’acl par défaut associé au répertoire perso de l’utilisateur :

getfacl prof1/perso
# file: prof1/perso
# owner: prof1
# group: root
user::rwx
user:prof1:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:prof1:rwx
default:group::---
default:mask::rwx
default:other::---

Il faudrait préciser le contexte de la demande initiale (quelle interface est utilisée, quelles sont les acls du répertoire perso et du fichier créé).

Bonjour,

Oui le problème se pose bien depuis l'application EOP.

Voici les ACLs sur un fichier.

# getfacl /home/adhomes/<uid>/perso/mot*
getfacl : suppression du premier « / » des noms de chemins absolus
# file: home/adhomes/<uid>/perso/mot-de-passe_19_9_0.csv
# owner: root
# group: root
user::rw-
user:17690:rwx                  #effective:rw-
group::---
mask::rw-
other::---

Mais il me semble que c'est avant tout un problème d'accès Unix :

# ll /home/adhomes/<uid>/perso/mot*
-rw-rw----+  1 root           root               100 sept. 19 13:25  mot-de-passe_19_9_0.csv

Un chown <uid>:root devrait permettre l'accès ?

Merci !
Laurent

La correction proposée met en œuvre ce changement de propriétaire.
Cependant, l’ACL supplémentaire qui est placée sur ce fichier devrait suffire à donner l’accès.

Est-ce que l’ACL user (17690) correspond bien à l’utilisateur et est-ce que la sortie non filtrée (J’imagine que le copié-collé est anonymisé) affichait plutôt un nom d’utilisateur ?

Il est possible que la correction apportée masque un autre problème.

J'ai bien remplacé le nom d'utilisateur dans la commande et les affichages par <uid>.

17690 apparait dans les ACLs d'autres fichiers de cet utilisateur donc il ne semble pas y avoir confusion à ce niveau.

Pour l’instant, les différents tests effectués ne permettent pas d’éclairer pourquoi le fichier n’est pas lisible par l’utilisateur à l’initiative de sa création.

Les étapes suivies sont les suivantes :
- attribution d’une classe à un professeur (les données de tests nécessitent cette étape de préparation)
- connexion à /eoleapps/eop avec le compte de ce professeur
- modification des mots de passe pour les élèves de toute la classe (soit mot de passe aléatoire, soit mot de passe unique, avec ou sans l’option de forcer la modification à la première connexion)
- ouverture du fichier sauvegardé par la procédure dans le répertoire perso avec libreoffice depuis une session ouverte avec le compte du professeur sur une machine windows 10 jointe au domaine.

Ce résultat de test semble suffisant pour déterminer que l’ACL par défaut ajoutée au fichier lors de sa création est suffisante pour permettre l’accès.

Dans le cas classique, getfacl remplace l’uid par le nom de l’utilisateur. C’est assez troublant de voir l’uid à la place, comme si la correspondance ne pouvait plus être trouvée. Les commandes id, wbinfo -i et getent passwd devraient donner des résultats cohérents.

Nous n’avons pas encore pu déterminer la cause première de l’interdiction d’accès. Il faudrait tester deux autres cas :
- côté Windows, l’id associé aux fichiers est l’utilisateur (ou l’id de l’AD) ;
- sur le serveur, il est possible d’accéder au fichier depuis une session ouverte avec le compte (su -s /bin/bash - <login>)

Bonjour,

Re-testé sur Scribe 2.8 à jour. Un changement via EOP produit un fichier qui est accessible aux enseignants :
(en 1er, test du jour, en 2ème, un fichier produit en octobre)

ll /home/adhomes/<uid>/perso/mot*
-rw------- 1 l.bri root  78 déc.  17 13:48 /home/adhomes/<uid>/perso/mot-de-passe_17_12_0.csv
-rw------- 1 root  root  80 oct.  28 12:59 /home/adhomes/<uid>/perso/mot-de-passe_28_10_0.csv

getfacl /home/adhomes/<uid>/perso/mot*
getfacl : suppression du premier « / » des noms de chemins absolus
# file: home/adhomes/<uid>/perso/mot-de-passe_17_12_0.csv
# owner: <uid>
# group: root
user::rw-
group::---
other::---

# file: home/adhomes/<uid>/perso/mot-de-passe_28_10_0.csv
# owner: root
# group: root
user::rw-
group::---
other::---

Peut-être corrigé par :

Les paquets candidats annoncés le 12/11/2024 seront diffusés en version stable le mercredi 20/11/2024.

Modifications diffusées pour les versions EOLE >= 2.8.0

    EOP
        Correction des droits sur les fichiers de mot de passe générés

Merci !
Laurent

Suite à demande de Joël, je confirme que le problème est bien résolu :

Avant :

cat /home/adhomes/<uid>/perso/mot-de-passe_23_9_0.csv
cat: /home/adhomes/<uid>/perso/mot-de-passe_23_9_0.csv: Permission non accordée

Maintenant :

cat /home/adhomes/<uid>/perso/mot-de-passe_17_12_0.csv
CLASSE;NOM;PRENOM;LOGIN;MOT DE PASSE;
etc.

Donc problème résolu !
Merci !
Laurent