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

Posté par . Licence CC by-sa.
0
20
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 . É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 . É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 . É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 . Évalué à 3. Dernière modification le 22/12/17 à 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 ?

    • [^] # Re: hard link ou sudo

      Posté par . Évalué à 3. Dernière modification le 21/12/17 à 10:04.

      À ma connaissance tu ne peux pas avoir des permissions différentes sur un lien physique et sur l'original. En effet, il me semble que les permissions sont enregistrées au niveaux des inodes.

      Je ne vois vraiment pas comment tu peux faire sans modifier les droits d'accès ou utiliser les ACLs.

  • # Maintenance impossible ?!

    Posté par (page perso) . É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 . É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 . É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

  • # Accéder au contenu du fichier

    Posté par . É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 . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.