Forum Linux.général Créer un lien symbolique avec des permissions différentes de la source ?

Posté par JuGuSm le 20 décembre 2017 à 22:26. Licence CC By‑SA.

Étiquettes :

déc.

2017

Bonjour,

J'ai besoin de donner l'accès à des fichiers qui appartiennent à root à un utilisateur applicatif mais j'ai quelques contraintes :

Je ne peux pas modifier les permissions de ces FICHIERS car il s'agit de log système donc question de sécurité.
Je ne peux pas utiliser les permissions ACL car il s'agit de milliers de machines et que la maintenance de ces droits serait impossible.
Je ne peux pas mettre en place un logrotate car j'ai besoin d'accéder à ces fichiers quasiment en temps réel et appliquer un logrotate aussi fréquemment dégraderait très fortement les performances.

Du coup je cherche une solution et je me demandais si un lien symbolique pouvait prendre des permissions différentes de celles du fichier d'origine pour ne donner l'accès qu'à mon user applicatif.

Merci d'avance pour votre aide.

# hard link ou sudo

Posté par eggus le 21 décembre 2017 à 00:50. Évalué à 0.

Un lien symbolique non.

Tu peux tenter avec un hard link mais ça oblige à être sur le même fs.

Autre solution : tu configures ton sudo pour permettre à l'utilisateur en question de lancer la commande cat /mon/fichier/de/log en tant que root.
- [^] # Re: hard link ou sudo
  
  Posté par JuGuSm le 21 décembre 2017 à 07:02. Évalué à 0.
  
  Le hard link m'intéresse, je vais creuser, merci.
  
  Le sudo n'est pas exploitable car il s'agit d'un user applicatif donc on ne connecte pas avec cet utilisateur, c'est l'application qui lit directement les fichiers et on ne peut pas lui spécifier d'utiliser le sudo.
  - [^] # Re: hard link ou sudo
    
    Posté par JuGuSm le 21 décembre 2017 à 09:48. Évalué à 1.
    
    Je viens de tester le hard link, ça ne fonctionne pas. Le changement s'applique aux deux fichiers :(
  - [^] # Re: hard link ou sudo
    
    Posté par Marotte ⛧ le 22 décembre 2017 à 00:47. Évalué à 3. Dernière modification le 22 décembre 2017 à 00:52.
    
    Le sudo n'est pas exploitable car il s'agit d'un user applicatif donc on ne connecte pas avec cet utilisateur
    
    Utilisateur désactivé et/ou nologin comme shell ? Un configuration spéciale déjà au niveau de sudo ?
    
    Ça n’a pas l’air simple https://askubuntu.com/questions/243346/how-to-run-a-command-as-a-user-whose-login-is-disabled mais ça me surprend cette soit disant limitation… tu as un lien ?
    
    c'est l'application qui lit directement les fichiers et on ne peut pas lui spécifier d'utiliser le sudo.
    
    C’est sûr que ça a un côté un peu sale mais c’est tout le script qu’il s’agit de lancer avec les droits root à l’aide de sudo… De toute façon, s’il doit accèder a des fichiers appartenant à root ce script… c’est bizarre dès le départ… root devrait mettre à disposition le fichier, pour un utilisateur donné, avec un "named pipe" peut-être… si ça doit être un accès permanent… et le reste des traitements exécutés en simple utilisateur.
    
    De quelle application s’agit-il ?
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 21 décembre 2017 à 10:03. Évalué à 3. Dernière modification le 21 décembre 2017 à 10:04.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# Maintenance impossible ?!

Posté par Cyril Brulebois (site web personnel) le 21 décembre 2017 à 02:12. Évalué à 3.
Je ne comprends pas pourquoi gérer des ACL serait plus dur (encore moins « impossible ») que n'importe quel autre mécanisme que tu pourrais mettre en place.

Si tu as des milliers de machines, tu utilises nécessairement un outil de configuration type ansible ou puppet donc il suffit de faire le travail une seule fois.

Pour les liens symboliques, citons la page de manuel de chmod :
```
chmod  never changes the permissions of symbolic links; the chmod system call cannot change their permis‐
sions.  This is not a problem since the permissions of symbolic links are never used.  However, for  each
symbolic  link listed on the command line, chmod changes the permissions of the pointed-to file.  In con‐
trast, chmod ignores symbolic links encountered during recursive directory traversals.
```
Debian Consultant @ DEBAMAX
- [^] # Re: Maintenance impossible ?!
  
  Posté par JuGuSm le 21 décembre 2017 à 07:06. Évalué à 2.
  
  Les équipes qui gèrent ces machines n'ont jamais utiliser les ACL, donc si est difficile de leur imposer une maintenance supplémentaire sur un grand nombre de machines.
  
  De plus, le parc étant très hétérogène, ansible ou puppet c'est pas pour tout de suite… Par exemple les images système des serveurs AIX n'intègrent pas les pré-requis pour ansible. Idem pour Windows.
# Solution de contournement

Posté par Marco le 21 décembre 2017 à 11:52. Évalué à 1.

J'ai peut être une solution : utiliser un script bash

Tu créer un script bash qui prend en paramètre le fichier de ton user et qui l'affiche par exemple
Le propriétaire de ce fichier bash est root et tu le rend executable par ton utilisateur mais il ne doit pas pouvoir être modifié en écriture.
Ensuite il faut manipuler le setuid, de façon à ce que quand l'utilisateur utilise ton script, il l'execute avec les droits root
https://fr.wikipedia.org/wiki/Setuid
- [^] # Re: Solution de contournement
  
  Posté par Dabowl_75 le 21 décembre 2017 à 14:56. Évalué à 5.
  
  Le setuid ne fonctionne pas pour les scripts et c'est tant mieux
  - [^] # Re: Solution de contournement
    
    Posté par Marco le 21 décembre 2017 à 16:08. Évalué à 2.
    
    Je l'ignorais merci pour l'info
    
    Mais du coup il peut utiliser le fichier sudoers pour autoriser son utilisateur à executer cat et certaines commandes spécifiques via sudo.
    Ca résoudrais son problème non ?
    
    https://doc.ubuntu-fr.org/sudoers
# Accéder au contenu du fichier

Posté par Dabowl_75 le 21 décembre 2017 à 14:55. Évalué à 3.

Ta problématique est d'accéder au contenu du fichier, pas forcément au fichier lui-même.

S'il s'agit de logs système alors tu peux contourner le problème en configurant syslog pour envoyer ces flux sur le réseau vers un serveur concentrateur. Ou bien tu peux demander à syslog d'écrire dans d'autres fichiers sur lesquels tu positionneras d'autres droits.

C'est un peu plus lourd à mettre en place mais si c'est pérenne et que tu as d'autres besoins similaires par la suite, ça peut valoir le coup.

Ou sinon, comme il a été dit, utiliser un script qui accedera au fichier et qui sera invoqué via un sudo.

Le setuid sur les scripts ça ne fonctionne pas et c'est tant mieux.

https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
# donner les droits au bon groupe

Posté par NeoX le 21 décembre 2017 à 20:16. Évalué à 5.

ton fichier est surement en mode
drwx------ root:root lefichier

tu peux tres bien changer le groupe propriétaire chown root:legroupe lefichier
drwx------ root:legroupe lefichier

puis les droits pour les utilisateurs du groupe chmod 740 lefichier
drwxr----- root:legroupe lefichier

puis ajouter ton utilisateur applicatif au groupe adduser -G legroupe leuser

cela devrait alors permettre à l'utilisateur de faire un cat lefichier
evidemment il faut remonter les droits sur les dossiers au dessus si besoin
- [^] # Re: donner les droits au bon groupe
  
  Posté par JuGuSm le 06 janvier 2018 à 00:47. Évalué à 1.
  
  C'est ce qui a finalement été retenu mais c'est pas du tout évident car il faut appliquer cette modification sur des milliers de machines
  - [^] # Re: donner les droits au bon groupe
    
    Posté par NeoX le 06 janvier 2018 à 10:28. Évalué à 2.
    
    tu aurais aussi eu à le faire si tu voulais utiliser les ACLs
    
    c'est le probleme de faire une modification à POSTERIORI

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.