[SUITE_IXUS] SME 7.5 - Session Shell Admin = Impossible

[HP77]

Bonjour,

Je reviens sur un sujet que j'avais ouvert sur l'ancien forum: SME 7.5 - Session Shell Admin = Impossible

En resume:
- Probleme toujours present :
- Imposibilite d'utiliser le login 'admin' depuis le Shell ou a distance via SSH (access denied)


Je viens juste de (re?)faire l'essai suivant (suggere' par Stirner, a ll'epoque, mais dont le resultat n'avait pas ete communique... ):

Code : Tout sélectionner

db accounts setprop admin Shell /bin/console
signal-event user-modify admin

Code : Tout sélectionner

[root@172.27.18.250 ~]# db accounts setprop admin Shell /bin/console
[root@172.27.18.250 ~]# signal-event user-modify admin
[root@172.27.18.250 ~]# su admin
su: /bin/console: No such file or directory
[root@172.27.18.250 ~]#


Resultat:
Aucune amelioration et perte de la commande "su".
Je "souligne" au passage une erreur concernant le Shell = /sbin/e-smith/console et non PAS /bin/console

Dans l'entre-faits, j'ai eu droit a un message d'erreur de M$-WinXP: "Server unexpectedly closed network connection" apres 5-10 secondes pour toute nouvelle tentative de connexion SSH : (SME_)DenyHosts ayant "blackliste" mon PC a cause des problemes avec le compte 'admin' ...

Bon, ayant conserve ma premiere session SSH ouverte, j'ai donc tente' un retour au parametre Shell par defaut pour 'admin' (obtenu depuis mon autre serveur SME):

Code : Tout sélectionner

[root@172.27.18.250 ~]# db accounts setprop admin Shell /sbin/e-smith/console
[root@172.27.18.250 ~]# su - admin
su: /bin/console: No such file or directory
[root@172.27.18.250 ~]# signal-event user-modify admin
[root@172.27.18.250 ~]# su - admin
Real UID cannot exec script
[root@172.27.18.250 ~]#


Cette fois-ci, cela me donne une piste : "Real UID cannot exec script" mais pas encore le resultat attendu par defaut : la console SME. Donc, probleme toujours entier (meme si je sais comment acceder a la console en etant 'root').

Une recherche rapide avec "real uid cannot exec script" m'a conduit a ceci:
- http://bugs.contribs.org/show_bug.cgi?id=2802
- - http://bugs.contribs.org/show_bug.cgi?id=2007
- - - http://bugs.contribs.org/show_bug.cgi?id=4947


En resume':
- D'apres le contenu du "bugtrack" 4947, Charlie Brady annonce une limitation a 32 groupes (j'en avais deja 55 il y a plus d'un an...)
- Charlie Brady a indique un "workaround" dans le "bugtrack" 2007 (commentaire 34) pour remedier au probleme ; le probleme semble se resoudre d'apres l'utilisateur Pierluigi Miranda ("bugtrack" 2802 - Commentaire 12):

- Faire une sauvegarde de tous les groupes : # ???

- Retirer 'admin' de tous les groupes sauf des groupes 'admin', 'root', 'www' et 'shared': # /usr/sbin/usermod -G admin,root,www,shared admin

- Essayer de se logger en tant que 'admin' et, depuis la console, choisir 'reconfigurer le serveur' avant de rebooter.
( sinon, la recette "traditionnelle" devrait tres bien faire l'affaire : # signal-event post-upgrade; signal-event reboot

- Re-integrer l'utilisateur 'admin' dans tous les groupes ou il s'y trouvait : # /usr/sbin/usermod -G admin,root,www,shared,group1,group2,... admin (group1,group2,... etant a remplacer par les groupes qui ont ete crees via Server-Manager...)

- C'est enfin termine' !

Bon, je vais rechercher comment faire la sauvegarde des groupes avant d'appliquer "la pommade anti-bobo".


Cordialement,
HP_

[unnilennium]

sur sme

le login à la ligne de commande de l'utilisateur admin ne permet que d’exécuter la commande console qui se lance directement.


Pour toutes taches d’administration créer un utilisateur dédié ou utiliser root.

le bug cité fait que on peut uniquement executer consol en se logant en root.

ce qui n'Es tpas un problème en soit car de totue façon le password des deux utilisateurs est le même.

[unnilennium]

puis l'édè de supprimer l'Admin des groupes :
[quote=Charlie Brady] could you please see whether this fixes the problem:

/usr/sbin/usermod -G admin,root,www,shared admin

There might be some things that don't work (e.g. admin won't be able to write to all i-bays via samba) but they will be less drastic than the console not working.[/quote]

pour ce coups là je suis pas d'Accord , qu'Est ce qui est le pire :
- ne plus pouvoir accéder aux dossier des ibays en tant qu'admin via samba ,
ou
- ne pas pouvoir accéder à la commande console en se loguant en admin alors qu'on peut le faire avec le même mot de passe en root en tapant console ?

ca reste un bug de perl qui ne supporte pas les utilisateurs avec plus de 32 appartenance a des groupes.

maintenant effectivement tu porurais ecrire un script qui :
- sauvegarde les groupes ou est l'Admin
- supprime l'Admin des groupes non de base,
- lance la console

verifier que si tu ferme la console brutalement ( killer Putty par exemple) l'Admin se retrouevr avec ses groupes ...
- remets tous les groupes d'avant à l'Admin

[HP77]

Bonjour,

Juste pour clarifier la situation sans avoir a tout relire depuis les archives du forum IXUS o`u avait commence'e cette discussion:

- L'acces a la console SME se faisant par defaut lors d'une session Shell avec le compte 'admin' pose effectivement probleme si l'utilisateur 'admin' fait parti de nombreux groupes (32 serait la limite "officielle", incluant des groupes non crees via Server-Manager (admin, root, shared, www))

- Une parade au probleme est bel et bien la possibilite d'acceder a cette console SME via une session shell en tant qu'utilisateur 'root' via la commande # console.

- Le "souci" est plutot de conserver "la philosophie SME" concernant la separation des comptes 'root' et 'admin' qui, sauf erreur de ma part peuvent maintenant fonctionner avec des mots de passe differents (ce qui est souhaitable pour deux utilisateurs differents ayant des "pouvoirs" differents). Maintenant, si c'est la meme personne qui se chargera "toujours" de tout, ce n'est pas pus genant que cela.

...
ca reste un bug de perl qui ne supporte pas les utilisateurs avec plus de 32 appartenance a des groupes.
...

Effectivement, comme tu le dis ci-dessus, cette affaire de limitation peut aussi concerner d'autres utilisateurs mais, comme le Shell est, par defaut, interdit aux utilisateurs, cela ne s'est jamais fait remarquer... j'avait toujours pense, a tort, que seul le compte 'admin' etait concerne' de part ses specificites...

Bien vu !


Bon, a part "mettre les mains dans le moteur" a la recherche de ce(s) script(s) en Perl pour remedier a cette limitation, il y a la methode de Charlie Brady, meme si elle ne me semble pas tres "propre" du fait qu'elle semble n'intervenir qu'a un seul endroit (? = les groupes) et que, s'il y a d'autres implications (mon flair / instinct / etc... me disent que probablement, Oui), cela pourrait avoir "des effets de bord" imprevus sur d'autres choses...
N'aimant pas les bricolages improvises, je prefere m'abstenir sur ce coup-la.


Concernant la mise a l'equerre de ce(s) script(s) en Perl, cela me tente bien mais j'ai encore beaucoup a apprendre sur Perl avant de pouvoir pretendre debugger quoi que ce soit dans ce langage. partie remise a plus tard...


Actuellement, ce qui m'a fait revenir vers ce probleme (contourne' via le compte utilisateur 'root' ...), c'est que je me retrouve dans une impasse blocante d'impossibilite d'acces au WebMail pour le compte 'admin' et je me demandais s'il n'y aurait pas, "par hasard", un lien quelconque du fait que le probleme touche a la configuration du systeme SME ...

Je viens juste de verifier avec mon propre compte d'utilisateur : meme probleme ! :think:
En essayant avec un compte utilisateur de test, lui, a bien acces a ses e-mails via le WebMail. :think:
Les deux comptes etant presents dans de nombreux groupes, cela semble etre un point commun assez evident, maintenant.


Je crois que je vais en rester la pour le moment. Ca donne matiere a reflechir davantage mais je n'en ai pas le temps ce matin.


A plus tard, si possible.

Cordialement,
HP_


P.S.

...
qu'Est ce qui est le pire :
- ne plus pouvoir accéder aux dossier des ibays en tant qu'admin via samba ,
ou
- ne pas pouvoir accéder à la commande console en se loguant en admin alors qu'on peut le faire avec le même mot de passe en root en tapant console ?

C'est sur que les partages reseau ne sont pas contournables aussi facilement (il y a bien WinSCP pour M$-W...)

...
ca reste un bug de perl qui ne supporte pas les utilisateurs avec plus de 32 appartenance a des groupes.

Oups ! J'aurais mal lu !?!
Tu veux dire un bug de Perl et non pas dans un ou plusieurs scripts en Perl ?
Si c'est le cas, ca fait tres mal si impossible de contourner le probleme simplement !

...
maintenant effectivement tu porurais ecrire un script qui :
- sauvegarde les groupes ou est l'Admin
- supprime l'Admin des groupes non de base,
- lance la console

A ce prix-la, j'ajouterais la fonction "preparation du petit dejeuner avec le cafe et les croissants".

...
verifier que si tu fermes la console brutalement ( killer Putty par exemple) l'Admin se retrouevr avec ses groupes ...
- remets tous les groupes d'avant à l'Admin

La, par contre, ca m'interesse de pouvoir distinguer une coupure de connexion a la sauvage (Putty ferme de force ou interruption de la connexion reseau) d'une fin de session normale.
Si tu connais le truc, je suis preneur. Autrement, je demanderais a "GG"...

[unnilennium]

WinSCP c'Est raté par defaut le compte admin a le droit à la commande console comme shell... dure de faire tourner scp

Les bugs expliquent bien un bug de Perl, et non des script en Perl.

Le truc en remplaçant le shell console par un shell maison appelant console et faisant ce qui est précité, c'est que je ne suis pas sur qu'en cas de coupure de connexion la fin du script soit executé ... d'où un admin sans groupes et la liste des groupes perdus à moins d'en faire une sauvegarde dans un fichier...


bref il y a toujours le compte root

[HP77]

Hello,

WinSCP c'Est raté par defaut le compte admin a le droit à la commande console comme shell... dure de faire tourner scp

Oui, c'est vrai ! Et dire que je connais ce "defaut"...

Les bugs expliquent bien un bug de Perl, et non des script en Perl.

OK. Donc, ce n'est definitivement pas dans mes cordes pour un certain temps.

Le truc en remplaçant le shell console par un shell maison appelant console et faisant ce qui est précité, c'est que je ne suis pas sur qu'en cas de coupure de connexion la fin du script soit executé ... d'où un admin sans groupes et la liste des groupes perdus à moins d'en faire une sauvegarde dans un fichier...


bref il y a toujours le compte root

Exactement, c'est pour ca que, de ce point de vue, je ne me risque meme pas de bricoler quoi que ce soit.
L'essai tente hier sur l'idee de Stirner n'apporte pas de solution.
Si je change le Shell du compte 'admin' par /bin/bash, ca fonctionne mais si je reviens au reglage par defaut, je n'obtient que ce message d'erreur:
"Real UID cannot exec script".


Donc, conclusion:
- a part ouvrir un nouveau sujet concernant ce bug pour dire qu'il fait toujours parler de lui, je ne vois pas grand chose d'autre a faire a mon niveau a part patienter que quelqu'un de plus competent que moi se penche serieusement sur ce probleme.
(je deteste patienter sans rien (pouvoir) faire... mais pas le choix dans l'immediat. )

Cordialement,
HP_