[bash] Interdire à un script de remonter une arborescence.

Tawal · Le 31/08/2022, à 14:16

Hello,

Je me pose la question, et je ne vois pas comment y arriver : Est-il possible qu'un script soit "auto" limité à une branche de l'arborescence.
Pour illustrer :

#!/bin/bash

cd "$HOME"/Test

# Code limitant l'arborescence à ./**
# ....

cd "$HOME"   # Erreur
ls "$HOME"   # Erreur

En fait, interdire que toute commande impliquant une écriture/lecture ou changement de dossier, ne puisse aller au dessus du dossier Test.

Dernière modification par Tawal (Le 31/08/2022, à 14:21)

Vobul · Le 31/08/2022, à 14:32

Ce n'est pas le script qui doit avoir des permissions restrictives, mais le système de fichier/système d'exploitation.

Une idée : faire un utilisateur spécifique qui exécutera le script et le chrooter.

Watael · Le 31/08/2022, à 15:34

quelle étrange requête ! tu ne sais pas les commandes qui seront inscrites dans le script que tu es en train d'écrire ?
quel est l'objectif à plus long terme ?

admettons que les chemins soient passés en paramètres, tu sais certainement comment contrôler tout ou partie du chemin, et le comparer à la branche à laquelle tu ne veux pas que l'utilisateur tente d'accéder.

iznobe · Le 31/08/2022, à 15:34

Bonjour un approche différente , peut etre une solution .
apres ton CD , tu met le répertoire courant dans une variable et donc tu lis ou tu es placé pour comparer a la variable .
si different tu peux faire un exit ?

Vobul · Le 31/08/2022, à 15:57

Mais il est vrai qu'il faut que tu expliques ce que tu veux faire et pourquoi. Qui peut éditer ce script ? Dans quel but ?

Tawal · Le 31/08/2022, à 17:16

En fait, je suis en trin de réfléchir à une série de script pour me faire une "auto" configuration de mon environnement de bureau, installation perso de paquets, mise en place de service (user et system) etc.
Le tout, dans un cas où je devrais ré-installer (nouvelle machine par exemple), pour me faciliter (et ne pas oublier ) la configuration perso et les mise en place de fonctionnalités.

Certains de ces scripts auront besoin de droits root pour faire des créations/modifications de fichiers et appliquer des commandes "d'activation".

Et donc je pensais à un dossier Test pour tester les futurs scripts.
Ce dossier Test contient toute l'arborescence (dupliquée) nécessaire à l'action des différents scripts.
Avant de faire le moindre essai d'un script devant créer/modifier des fichiers/dossiers (même en utilisateur), j'ai subitement pensé à l'empêcher de remonter cette fameuse arborescence.

@Vobul : Ta 1ère idée/conseil est bonne, je pense.
Mais on entre dans un domaine que je maîtrise pas ou peu.

Edit:
Sinon, je pensais à créer un utilisateur test pour les essais de la configuration utilisateur (sans droits autres que d'écrire dans son $HOME).
Et pour la partie nécessitant des droits root, faire un chroot ? (encore un domaine que je connais pas ).

Dernière modification par Tawal (Le 31/08/2022, à 19:13)

Watael · Le 31/08/2022, à 19:40

chroot +1,
ou un conteneur lxc (simple et rapide, et plus complet),
ou une machine virtuelle.

Dernière modification par Watael (Le 31/08/2022, à 19:41)

Tawal · Le 31/08/2022, à 20:00

Oui, machine virtuelle, j'y avais pensé, mais je n'ai pas une machine réelle de guerre.
Donc trop lourd. (mais pas impossible).

Je pense que le chroot serai plus léger.
J'ai de la lecture à venir

Reste l'idée de l'utilisateur test sur ma machine réelle, pour les tests utilisateur.

Puis pour finir, une machine virtuelle pour tester en situation (presque) réelle une fois le sentiment d'être abouti..

Dernière modification par Tawal (Le 31/08/2022, à 20:58)

Watael · Le 31/08/2022, à 20:18

xlc, sur Intel Core i5 3.5GHz, et 8Go de ram (t'as moins ?), ça marche sans souci, mais je n'y mets pas d'interface graphique.

Tawal · Le 31/08/2022, à 20:31

Oui, j'ai bien moins. AMD Athlon(tm) X2 Dual-Core 1GHz, 4Go Ram.

Vobul · Le 31/08/2022, à 21:53

Regarde aussi du côté d'ansible. C'est ce qu'on utilise pour provisionner les serveurs mais ça peut très bien fonctionner pour un desktop également. Et utilise une machine virtuelle. Je ne vois pas comment tu peux tester l'installation d'un paquet/la configuration de tout un système avec un utilisateur test limité... En plus tu pourras facilement faire des snapshots à différentes étapes.

kholo · Le 02/09/2022, à 09:22

salut,
j'ai beaucoup bossé sur la post installation...
j'ai des tutos sur ce forum qui reprennent mes recherches et expliquent quoi et comment faire...
j'ai fini par me faire un ensemble de scripts qui configurent mes installations...
par exemple, à partir d'un script tout fait, j'ai modifié à ma sauce pour installer une batterie de logiciels depuis une liste que je maintient dans un fichier texte... bigrement efficace !
sinon j'ai des scripts pour la fin de francisation, mises à jour, changement du fond d'écran, ajout de profile Firefox ou Geany, réglage de la swap,...
sur mon site perso, j'ai mis mes scripts de ma 16.04 (pas mis à jour mais toujours fonctionnel) qui de donneront une idée
... et je peux te faire passer des choses plus récentes en MP que je ne diffuse pas sur ce forum ou sur le net si cela t'intéresse...

Tawal · Le 02/09/2022, à 14:40

Mon idée de base est ressemblante à la tienne.
J'envisage une base données avec des fichiers fixe et dynamique.
Donc évidemment une liste de paquets à installer, des fichiers de configuration à mettre en place, des éditions de fichiers déjà existants, des scripts perso, etc.

La collecte des informations et la mise en script d'installation de tout ça ne me pose pas trop de problèmes.
Ce qui me pose souci, c'est la partie test.
La virtualisation m'est trop lourde pour pouvoir "multiplier" mes essais.
Je pense que le meilleur "confinement" pour mes essais serait bien de "chrooter" un système de fichiers à part.
Je n'ai pas encore lu toute la documentation à ce sujet, mais il me semble bien que je pourrais faire un chroot sur une arborescence d'une installation fraîche.
En ayant importé au préalable mon projet.

C'est, je pense, la solution la plus légère en ressources.
Et elle répond à mon besoin d'isoler l'action d'un script.
Vobul a raison, c'est le système qui définit les permissions du script, pas le contraire.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 31/08/2022, à 14:16

[bash] Interdire à un script de remonter une arborescence.

#2 Le 31/08/2022, à 14:32

Re : [bash] Interdire à un script de remonter une arborescence.

#3 Le 31/08/2022, à 15:34

Re : [bash] Interdire à un script de remonter une arborescence.

#4 Le 31/08/2022, à 15:34

Re : [bash] Interdire à un script de remonter une arborescence.

#5 Le 31/08/2022, à 15:57

Re : [bash] Interdire à un script de remonter une arborescence.

#6 Le 31/08/2022, à 17:16

Re : [bash] Interdire à un script de remonter une arborescence.

#7 Le 31/08/2022, à 19:40

Re : [bash] Interdire à un script de remonter une arborescence.

#8 Le 31/08/2022, à 20:00

Re : [bash] Interdire à un script de remonter une arborescence.

#9 Le 31/08/2022, à 20:18

Re : [bash] Interdire à un script de remonter une arborescence.

#10 Le 31/08/2022, à 20:31

Re : [bash] Interdire à un script de remonter une arborescence.

#11 Le 31/08/2022, à 21:53

Re : [bash] Interdire à un script de remonter une arborescence.

#12 Le 02/09/2022, à 09:22

Re : [bash] Interdire à un script de remonter une arborescence.

#13 Le 02/09/2022, à 14:40

Re : [bash] Interdire à un script de remonter une arborescence.

Pied de page des forums