Fonds Linux
  1. Fonds Linux
  3. Comment bloquer l'access en lecture à un lien symbolique?
Intereting Posts
Supprimer un mot spécifique dans la variable Comment faire une search de profondeur max dans ack et grep? Les appels suivants à wpa_supplicant échouent – impossible de se connecter au wifi En attendant que le tunnel SSH (ssh -w) soit configuré avant d'exécuter la command Utilisez sed pour replace une partie d'une ligne par une variable Rendu OpenGL matériel dans MATLAB Comment limiter le nombre de connections actives par user? Puis-je simuler des mouvements de souris via le terminal sans xdotool? Comment puis-je empêcher les emacs de colorier le text du file que je suis en train d'éditer? Extraire l'adresse IP d'un text et la stocker dans une variable scp sans replace les files existants dans la destination updatedb: impossible d'ouvrir un file temporaire pour `/var/lib/mlocate/mlocate.db ' Mode_switch + Shift n'est pas la même chose que Shift + Mode_Switch? Comment démarrer manuellement le ventilateur sous Linux? df, du rapport d'utilisation incorrecte du disque

Comment bloquer l'access en lecture à un lien symbolique?

J'ai cette structure de file: 

> APPLICATION 1 >> CONTROLLER (@JuniorProgrammers) >> MODELS (symlink to SHARED/MODELS) >> VIEWS (@Designers) > APPLICATION 2 >> CONTROLLER (@JuniorProgrammers) >> MODELS (symlink to SHARED/MODELS) >> VIEWS (@Designers) > SHARED >> MODELS (@SeniorProgrammers)

J'ai besoin de php pour pouvoir lire le contenu du dossier 1.1, mais les programmeurs qui FTP dans le dossier 1 ne pourront pas lire le lien symbolique (ils PEUVENT voir le lien symbolique, mais pas le SUIVRE, y compris toutes les lectures et les écritures).

Les @ sont les groupes d'users disposant d'un access en lecture / écriture de chaque couche.

Symlinks eux-mêmes ont 777 parce que dans Unix, la security des files est évaluée sur une base file / inode. Si ce sont les mêmes données, elles doivent avoir les mêmes conditions de security, quel que soit le nom que vous avez donné au système pour l'ouvrir. 

 [root@hypervisor test]# ls -l total 0 lrwxrwxrwx. 1 root root 10 Jun 8 16:01 symTest -> /etc/fstab [root@hypervisor test]# chmod o-rwx symTest [root@hypervisor test]# ls -l total 0 lrwxrwxrwx. 1 root root 10 Jun 8 16:01 symTest -> /etc/fstab [root@hypervisor test]# :-(

Puisque les permissions sont définies sur l'inode, il ne fonctionnera pas avec les liens durs même: 

 [root@hypervisor test]# echo "Don't Test Me, Bro" > testing123 [root@hypervisor test]# ls -l total 4 lrwxrwxrwx. 1 root root 10 Jun 8 16:01 symTest -> /etc/fstab -rw-r--r--. 1 root root 19 Jun 8 16:06 testing123 [root@hypervisor test]# ln testing123 newHardLink [root@hypervisor test]# ls -l total 8 -rw-r--r--. 2 root root 19 Jun 8 16:06 newHardLink lrwxrwxrwx. 1 root root 10 Jun 8 16:01 symTest -> /etc/fstab -rw-r--r--. 2 root root 19 Jun 8 16:06 testing123 [root@hypervisor test]# chmod 770 testing123 [root@hypervisor test]# chmod 700 newHardLink [root@hypervisor test]# ls -lh total 8.0K -rwx------. 2 root root 19 Jun 8 16:06 newHardLink lrwxrwxrwx. 1 root root 10 Jun 8 16:01 symTest -> /etc/fstab -rwx------. 2 root root 19 Jun 8 16:06 testing123

Un lien symbolique n'est pas un inode (qui stocke réellement datatables que vous voulez sécuriser) ergo dans le model Unix, cela complique les choses en ayant deux sets différents d'permissions pour protéger les mêmes données.

On dirait que c'est une tentative de donner à différents groupes de personnes différents niveaux de droits d'access au même file. Si c'est le cas, vous êtes supposé utiliser les commands POSIX ACL (via setfacl et getfacl ) pour donner aux files les permissions appropriées sur la cible du lien symbolique.

MODIFIER:

Pour élaborer sur la direction que vous voulez probablement entrer, c'est quelque chose comme: 

 # setfacl -mu:apache:r-- "Folder 2.1" # setfacl -mg:groupOfProgrammers:--- "Folder 2.1" # setfacl -mg:groupOfProgrammers:rx "Folder 1"

Ce qui précède donne à l'user apache (substitut à n'importe quel user de votre access à la cible du lien symbolique) et donne à groupOfProgrammers access en lecture au directory dans lequel se groupOfProgrammers le lien symbolique (afin que groupOfProgrammers puisse accéder un directory complet répertoriant ici), mais transforme tous les bits d'autorisation pour la même cible du lien symbolique.

Nous ne soaps toujours pas ce que vous avez fait au niveau du système de files. L'approche habituelle consiste à faire de root (ou un autre count administrateur) le propriétaire de tous ces directorys et de donner les directorys de niveau 2 aux groupes avec les droits du propriétaire, rwx pour le groupe et aucun pour les others . Il peut être utile d'avoir aussi le bit collant ( chmod o+t "$dirname" ).

Les directorys de niveau 1 doivent appartenir à l'user et au groupe d'administration (par exemple root: root) avec les droits de rx pour les others .