exemple simple :
for i in $( find rep_protege -type 'f' )
do
mkdir -p "dest/$(dirname "$i")"
cat "$i" > "dest/$i"
done
et ça fait une copie récursive sans même utiliser cp...
y a aussi avec tar et autre... à partir du moment ou on peut lire, on peut copier.
ensuite on pourrait imaginer une arbo où on aurait viré cp tar et consort mais je ne suis même pas sur que ça resiste au shell
while read l < fich
do
echo $l>> dest
done
( à travailler )
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Pour traverser un répertoire, il faut avec les droits "d'exécution". Pour lister un répertoire, il faut les droits en lecture. Que signifie pour toi "l'accès en lecture d'un répertoire" ? Si c'est seulement voir la liste des fichiers qu'il contient, alors on peut restreindre "l'accès en copie" en interdisant la lecture des fichiers contenus dans le répertoire. En revanche, si tu cherches à interdire la copie de fichiers d'un répertoire, tout en permettant la lecture de ces mêmes fichiers, je crains bien que cela ne soit pas possible. Sous Linux, afficher un fichier à l'écran (i.e: le lire), c'est en fait le copier vers ton [pseudo-]terminal. le droit de "copie" en lui-même n'existe pas.
Tout d'abord merci de vos réponse car je pensais m'a demande farfelue .....
En fait j'ai des fichiers qui sont propriétaires qui doivent être charger dans une application mais je ne veux pas que mes utilisateurs copie ces fichiers dans leur HOME pour des raisons de copyright
Je pense que la conclusion est la suivant : ce n'est pas possible....
Si le fichier ne doit être lu que par une certaine application, tu peux regarder du côté de setuid : l'application peut être exécutée avec des droits différents de ceux de l'utilisateur, et pourra accéder à des fichiers que l'utilisateur ne peut pas lire directement.
si tu met les propriétaires de ton dossier à application.group
avec les droits 700 (seul l'utilisateur application peut lire/ecrire dedans)
si tu suid ton binaire pour qu'il soit aussi appartiennent aussi à application.group il pourra aller lire/ecrire dans ce dossier, meme si c'est user1 qui lance l'appli.
c'est le cas de beaucoup de daemon par exemple, qui, bien que lancer par root, se trouve etre attribué à un utilisateur (apache, ftp, nobody...)
# je ne vois pas comment
Posté par fearan . Évalué à 1.
for i in $( find rep_protege -type 'f' )
do
mkdir -p "dest/$(dirname "$i")"
cat "$i" > "dest/$i"
done
et ça fait une copie récursive sans même utiliser cp...
y a aussi avec tar et autre... à partir du moment ou on peut lire, on peut copier.
ensuite on pourrait imaginer une arbo où on aurait viré cp tar et consort mais je ne suis même pas sur que ça resiste au shell
while read l < fich
do
echo $l>> dest
done
( à travailler )
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Et Dieu dit: Tout sera fichier ...
Posté par ecid . Évalué à 1.
Pour traverser un répertoire, il faut avec les droits "d'exécution". Pour lister un répertoire, il faut les droits en lecture. Que signifie pour toi "l'accès en lecture d'un répertoire" ? Si c'est seulement voir la liste des fichiers qu'il contient, alors on peut restreindre "l'accès en copie" en interdisant la lecture des fichiers contenus dans le répertoire. En revanche, si tu cherches à interdire la copie de fichiers d'un répertoire, tout en permettant la lecture de ces mêmes fichiers, je crains bien que cela ne soit pas possible. Sous Linux, afficher un fichier à l'écran (i.e: le lire), c'est en fait le copier vers ton [pseudo-]terminal. le droit de "copie" en lui-même n'existe pas.
[^] # Re: Et Dieu dit: Tout sera fichier ...
Posté par dubis . Évalué à 2.
En fait j'ai des fichiers qui sont propriétaires qui doivent être charger dans une application mais je ne veux pas que mes utilisateurs copie ces fichiers dans leur HOME pour des raisons de copyright
Je pense que la conclusion est la suivant : ce n'est pas possible....
[^] # Re: Et Dieu dit: Tout sera fichier ...
Posté par ✅ ffx . Évalué à 2.
[^] # Re: Et Dieu dit: Tout sera fichier ...
Posté par dubis . Évalué à 1.
Un avis ???
[^] # Re: Et Dieu dit: Tout sera fichier ...
Posté par ragoutoutou . Évalué à 2.
Maintenant, faire un suid de l'application ou la lancer via sudo, ça reste une solution simple et mieux intégrée à la sécurité OS...
[^] # Re: Et Dieu dit: Tout sera fichier ...
Posté par NeoX . Évalué à 2.
application.group
avec les droits 700 (seul l'utilisateur application peut lire/ecrire dedans)
si tu suid ton binaire pour qu'il soit aussi appartiennent aussi à application.group il pourra aller lire/ecrire dans ce dossier, meme si c'est user1 qui lance l'appli.
c'est le cas de beaucoup de daemon par exemple, qui, bien que lancer par root, se trouve etre attribué à un utilisateur (apache, ftp, nobody...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.