Discussion :

[rufa11]

Bonjour,

SVP quelle est la meilleur façon de créer un user aux droits administratifs limités à quelque commandes seulement, par exemle quand il tape log dans le shell il va voir que les logs de apache....


Merci.

[rufa11]

sudoers peut faire ça.

[frp31]

selon le besoin reel chroot est aussi une bonne solution

[LittleWhite]

Bonjour,

Je me trompe certainement, mais moi, j'utilisais sudoers dans l'autre sens (donner des accès non restreint/sans nécessité d'autorisation admin) à un utilisateur simple.

[BufferBob]

Je me trompe certainement, mais moi, j'utilisais sudoers dans l'autre sens (donner des accès non restreint/sans nécessité d'autorisation admin) à un utilisateur simple.

tu te trompe pas tout dépend de ce qu'on entend par "droits limités" mais il il peut être intéressant de regarder du coté d'un shell restreint (comme rbash ?) voire si l'utilisateur n'ouvre sa session que via ssh regarder comment restreindre une clé privée par exemple, ou simplement gérer un peu mieux les droits unix sur le système de fichiers (chown/chmod), et au delà comme dit un chroot ou mieux un jail, etc. c'est pas exhaustif et il y a pleins de façons de faire, tout dépend du besoin

dans le cas cité plus haut d'une commande log (qui n'existe pas par défaut) qui permettrait d'afficher les logs apache pour un user en particulier, il suffirait simplement de faire un script et d'en autoriser la lecture ou non via chown/chmod

[frp31]

l intérêt d un chroot c est qu le user a son propre / son propre /bin etc ......donc qu une liste exacte de commandes ni plus ni moins

par exempl il peux avoir ls mais pas df si on veut....

[jlliagre]

Oui, mais le problème avec un chroot, c'est que l'utilisateur sera enfermé dedans et ne pourra pas exécuter les commandes d'administration souhaitées par rufa11.

Un shell restreint (rbash, rksh) répond parfaitement au besoin. Il suffit de mettre dans le PATH de l'utilisateur en question un seul répertoire contenant uniquement des scripts appelant les commandes auxquelles il a droit, via sudo si nécessaire.

[rufa11]

Bonjour,

Merci beaucoup pour vos réponses, en effet comme vous l'avez cité il y a plusieurs façons de le faire sudoers,rbash,chroot (mèttre etc... avec quelques commandes seulement)..., j'ai opté pour sudoers car elle permet de restreint/donner des accès à un user (NOPASSWD: car je ne veux pas leur donner le password)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 identifiant	ALL = (user) NOPASSWD: /chemin/complet/commande,/chemin/complet/autrecommande

, dans mon cas il sagit de donner de permèttre aux développeurs d'éxécuter quelques commandes comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

apachectl configtest, systemctl apache stop,start,restart....

chose qu'on peux faire avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudoers via visudo

en mode admin, pour les logs il suffit juste de faire un petit script qui peut afficher les logs en mode read only

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
tail -f -n xxxx, vi -R,....   
chmode +x path_to_the_script

et enfin faire un mv des scripts à /usr/bin (tout déprend de la distribution Linux).

Merci encore.

[Escapetiger]

et enfin faire un mv des scripts à /usr/bin (tout déprend de la distribution Linux).

Comme c'est du spécifique, le mieux sera encore /usr/local/bin (ISO fonctionnel en cas d'upgrade du serveur ...), vérifier si le PATH est inclus dans l'environnement du user administratif concerné.

[BufferBob]

accessoirement :

dans mon cas il sagit de donner de permèttre aux développeurs d'éxécuter quelques commandes comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

apachectl configtest, systemctl apache stop,start,restart....

en général on évite de faire ça, la gestion et la bonne marche du serveur relevant de la responsabilité de l'admin, et non celle du dev

on aura en général plutôt tendance à créer un script permettant d'automatiser un maximum de choses, typiquement pousser le code, faire les modifs en base, redémarrer l'apache, le tout sur la machine de recette ou de pré-production uniquement évidemment, pour une MEP l'accompagnement d'un admin pour superviser l'opération, effectuer un rollback éventuel et s'assurer que tout est validé coté dev reste necéssaire

[rufa11]

Comme c'est du spécifique, le mieux sera encore /usr/local/bin (ISO fonctionnel en cas d'upgrade du serveur ...), vérifier si le PATH est inclus dans l'environnement du user administratif concerné.

Oui vous avez raison, comme c'est du CentOS 6.8 donc le /usr/bin/ est dans la variable d'environnment PATH.

Merci à vous.

accessoirement :

en général on évite de faire ça, la gestion et la bonne marche du serveur relevant de la responsabilité de l'admin, et non celle du dev

on aura en général plutôt tendance à créer un script permettant d'automatiser un maximum de choses, typiquement pousser le code, faire les modifs en base, redémarrer l'apache, le tout sur la machine de recette ou de pré-production uniquement évidemment, pour une MEP l'accompagnement d'un admin pour superviser l'opération, effectuer un rollback éventuel et s'assurer que tout est validé coté dev reste necéssaire

Je pense que j'ai oublié de mentionner que ce sont des machines de test et dev, pour les machines de prod c'est nous admin qui feront le déploiement, de plus j'ai donnè accès en read only aux fichiers httpd.conf et my.cnf, je pense que je vais faire un script pouyr automatiser ça, je vais discuter avec les collègues pour ça.

Merci à vous.

[Escapetiger]

Oui vous avez raison, comme c'est du CentOS 6.8 donc le /usr/bin/ est dans la variable d'environnment PATH.

Ah, les joies du copié / collé : /usr/local/bin


[Edit]

https://fr.wikipedia.org/wiki/Filesy...archy_Standard
Filesystem Hierarchy Standard — Wikipédia

...



Source (je ne sais pas si elle est pérénne) :

https://www.google.fr/?gws_rd=ssl#q=ClPkUMRWgAADjiW.jpg

[rufa11]

Merci,

C'est pas du copy/paste lol, mais j'ai préférér mèttres mes commandes avec les binaries /usr/bin: