Forum Linux.général Une belle colle !

Posté par  (site web personnel) .
Étiquettes : aucune
0
15
juin
2006
Bonjour,

Je suis tombé aujourd'hui sur un sujet d'examen (qui date d'un an), simple au demeurant, mais l'une des questions me semble tout simplement insoluble. Le problème supplémentaire étant que les questions s'enchaînent, ce qui fait que je suis obligé de retranscrire l'ensemble de cet exercice ici.

Le sujet commence par un conseil qui précise qu'il est important de procéder pas à pas, et enchaîne avec une description qui est la suivante:

Description de la racine:
drwxrwx--- 4 root APPLI 96 sep 3 2004 app
drwxrwx--- 4 root USERS 96 sep 3 2004 usr


Description "utile" du répertoire app:
drwxrwx--- 4 root APPLI 96 sep 3 2004 app1

Description du répertoire app1:
-rwxrwx--- 1 root APPLI 252 sep 3 2001 test
-rwxrwx--- 1 root APPLI 248 sep 3 2001 pgm_op


Description de /usr:
drwxrwx--- 4 root USERS 1024 sep 3 2004 user1
drwxrwx--- 4 root USERS 1024 sep 3 2004 user2

La suite explique que ces répertoires représentent les répertoires home des utilisateurs concernés (user1 et user2).

Les questions qui suivent sont simplistes ("quelle commande permet de lister un répertoire ?", ...) et la seul chose à retenir est que le groupe principal des deux utilisateurs est USERS.

User1 souhaite exécuter le programme "test" sans avoir à entrer l'intégralité de l'arbo, c'est à dire en entrant simplement le mot "test". Pour l'instant, Linux dit à user1, qui se trouve dans son home, qu'il ne trouve pas la commande. Vous êtes l'utilisateur root.

*) Comment allez-vous modifier dans un premier temps et sans toucher aux droits sur les fichiers/répertoires, l'environnement de l'utilisateur user1 pour qu'il puisse accéder à ce programme sans en saisir le chemin ?
J'imagine qu'il s'agit ici d'un changement du path (les rédacteurs du sujet on t'il conscience que "test" existe déjà ?) : PATH=/app/app1/:$PATH

*) Cette modification sera-t-elle aussi valide pour le programme pgm_op ?
En effet, ça resterait logique...

Vous venez de modifier l'environnement de user1, mais user1, lorsqu'il tape "test" se voit signifier que l'accès à test est interdit. Même chose pour "pgm_op".

*) Comment, sans toucher aux droits d'un quelconque fichier, donner le droit d'accès à test pour l'utilisateur user1 ?
Au vu des droits sur le répertoire, ajouter l'utilisateur user1 au groupe APPLI devrait faire l'affaire.

L'utilisateur user1 a maintenant le droit d'accéder à "test" et à "pgm_op", mais Linux dit à user1 qu'il ne peut executer aucun des programmes lorsqu'il tape "test" ou "pgm_op". Par ailleurs, user1 vous demande de pouvoir effacer le programme test et de pouvoir lancer le programme "pgm_op". De votre côté, vous ne souhaitez pas que l'utilisateur puisse effacer le programme "pgm_op".

*) Comment allez-vous modifier les droits des programmes ou de certains répertoires (ou les deux) pour satisfaire à la fois la demande de l'utilisateur user1 et vos propres exigences
C'est là que ca coince ! Ok pour les droits "x" manquants sur les fichiers, mais sachant que pour moi, l'effacement dépend uniquement des droits sur le répertoire "app1", je vois mal comment il est possible de se débrouiller pour qu'un seul des deux fichiers de ce répertoire soit effacable par user1.

La question suivante (qui est peut être un indice ?) demande si la modification apportée à cette question fait que user2 est toujours interdit d'exécution sur "test" et "pgm_op".

En ce qui me concerne (j'y ai pas passé des heures non plus), j'ai du mal à trouver une réponse simple à ce problème :) Et vous ?

  • # Peut-être une clownerie

    Posté par  . Évalué à 2.

    As-tu regardé du côté des acl ?
    Ou alors du côté des attributs étendus ?
    Je dis ça sans savoir, je n'ai que survolé ton message, et je donne ça de mémoire, pour y avoir regardé autrefois, sans grande conviction...

  • # Sticky bit

    Posté par  . Évalué à 5.

    C'est là que ca coince ! Ok pour les droits "x" manquants sur les fichiers, mais sachant que pour moi, l'effacement dépend uniquement des droits sur le répertoire "app1", je vois mal comment il est possible de se débrouiller pour qu'un seul des deux fichiers de ce répertoire soit effacable par user1.


    As-tu pensé à regarder du coté du sticky bit ?

    chmod +t

    • [^] # Re: Sticky bit

      Posté par  (site web personnel) . Évalué à 3.

      Quel idiot ! C'est évident maintenant :)

      Bravo !

      • [^] # Re: Sticky bit

        Posté par  . Évalué à 2.

        C'est peut être une bêtise, mais chattr ne serait il pas une solution pour empêcher l'effacement du fichier?

        • [^] # Re: Sticky bit

          Posté par  (site web personnel) . Évalué à 3.

          Au vu du sujet, je pense les questions portent avant tout sur Unix au sens large, et non spécifiquement à Linux (chattr est une "Linuxerie").

          • [^] # Re: Sticky bit

            Posté par  . Évalué à 1.

            Pourquoi dans les questions posées, il est inscrit Linux alors ?

  • # Et sudo

    Posté par  . Évalué à 2.

    Tu peux aussi le faire avec sudo.

    • [^] # Re: Et sudo

      Posté par  . Évalué à 3.

      Il n'est pas précisé que sudo est installé. Et par defaut,sur unix,sudo ne l'est pas.

      • [^] # Re: Et sudo

        Posté par  . Évalué à 2.

        Puis c'est quand même vachement sale, aussi ...

  • # noexec et sticky bit..

    Posté par  . Évalué à 1.

    quand un utilisateur est propriétaire d'un répertoire, il peut effacer tous les fichier de ce répertoire...cela peut être gênant...du coup on positionne le sticky bit sur le répertoire et le propriétaire ne peut plus effacer les fichiers du répertoire....seul l'utilisateur root peut positionner le sticky bit...

    Si ce même utilisateur ne peut exécuter aucun programme, c'est que le programme qu'il cherche à exécuter se trouve sur un système de fichier monté en "noexec"....en tapant la commande "mount" tout court, on voit rapidement là où ça coince...

Suivre le flux des commentaires

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