Trouver des fichiers qu'un utilisateur peut écrire, efficacement avec un minimum de création de processus

Je suis root. Je voudrais savoir si un utilisateur non root a un accès en écriture à certains fichiers - des milliers d'entre eux. Comment le faire efficacement tout en évitant la création de processus?

Peut-être comme ça:

#! /bin/bash

writable()
{
    local uid="$1"
    local gids="$2"
    local ids
    local perms

    ids=($( stat -L -c '%u %g %a' -- "$3" ))
    perms="0${ids[2]}"

    if [[ ${ids[0]} -eq $uid ]]; then
        return $(( ( perms & 0200 ) == 0 ))
    elif [[ $gids =~ (^|[[:space:]])"${ids[1]}"($|[[:space:]]) ]]; then
        return $(( ( perms & 020 ) == 0 ))
    else
        return $(( ( perms & 2 ) == 0 ))
    fi
}

user=foo
uid="$( id -u "$user" )"
gids="$( id -G "$user" )"

while IFS= read -r f; do
    writable "$uid" "$gids" "$f" && printf '%s writable\n' "$f"
done

Ce qui précède exécute un seul programme externe pour chaque fichier, à savoir stat(1).

Remarque: Cela suppose bash(1), et l'incarnation Linux de stat(1).

Note 2: Veuillez lire les commentaires de Stéphane Chazelas ci-dessous pour connaître les dangers et limites passés, présents, futurs et potentiels de cette approche.

TL; DR

find / ! -type l -print0 |
  sudo -u "$user" perl -Mfiletest=access -l -0ne 'print if -w'

Vous devez demander au système si l'utilisateur dispose d'une autorisation d'écriture. Le seul moyen fiable est de basculer l'uid efficace, le gid efficace et les gids de supplémentation sur celui de l'utilisateur et d'utiliser l' access(W_OK)appel système (même cela a des limites sur certains systèmes / configurations).

Et gardez à l'esprit que le fait de ne pas avoir la permission d'écrire sur un fichier ne garantit pas nécessairement que vous ne pouvez pas modifier le contenu du fichier sur ce chemin.

L'histoire la plus longue

Considérons ce qu'il faut , par exemple , pour un utilisateur $ pour avoir accès en écriture à /foo/file.txt( en supposant qu'aucun des /fooet /foo/file.txtdes liens symboliques)?

Il a besoin:

1. accès à la recherche/ (pas nécessaire read)
2. accès à la recherche/foo (pas nécessaire read)
3. accès en écriture à/foo/file.txt

Vous pouvez déjà voir que les approches (comme @ lcd047 ou @ apaul ) qui vérifient uniquement l'autorisation de file.txtne fonctionneront pas car elles pourraient dire file.txtest accessible en écriture même si l'utilisateur n'a pas l'autorisation de recherche pour /ou /foo.

Et une approche comme:

sudo -u "$user" find / -writeble

Ne fonctionne pas , soit parce qu'elle ne rapportera pas les fichiers dans les répertoires que l'utilisateur n'a pas d' accès en lecture (en findcours d' exécution que $userne peut pas la liste de leur contenu) , même s'il peut y écrire.

Si nous oublions les ACL, les systèmes de fichiers en lecture seule, les indicateurs FS (comme immuables), d'autres mesures de sécurité (apparmor, SELinux, qui peuvent même faire la distinction entre différents types d'écriture) et nous concentrer uniquement sur les attributs de permission et de propriété traditionnels, pour obtenir un étant donné (rechercher ou écrire) la permission, c'est déjà assez compliqué et difficile à exprimer find.

Vous avez besoin:

• si le fichier vous appartient, vous avez besoin de cette autorisation pour le propriétaire (ou avoir uid 0)
• si le fichier ne vous appartient pas, mais que le groupe est l'un des vôtres, vous devez disposer de cette autorisation pour le groupe (ou avoir uid 0).
• s'il ne vous appartient pas et n'appartient à aucun de vos groupes, les autres autorisations s'appliquent (sauf si votre UID est 0).

En findsyntaxe, ici à titre d'exemple avec un utilisateur de uid 1 et des gids 1 et 2, ce serait:

find / -type d \
  \( \
    -user 1 \( -perm -u=x -o -prune \) -o \
    \( -group 1 -o -group 2 \) \( -perm -g=x -o -prune \) -o \
    -perm -o=x -o -prune \
  \) -o -type l -o \
    -user 1 \( ! -perm -u=w -o -print \) -o \
    \( -group 1 -o -group 2 \) \( ! -perm -g=w -o -print \) -o \
    ! -perm -o=w -o -print

Celui-ci élague les répertoires que l'utilisateur n'a pas droit de recherche pour et pour d'autres types de fichiers (les liens symboliques sont exclus car ils ne sont pas pertinents), vérifie l'accès en écriture.

Si vous souhaitez également envisager l'accès en écriture aux répertoires:

find / -type d \
  \( \
    -user 1 \( -perm -u=x -o -prune \) -o \
    \( -group 1 -o -group 2 \) \( -perm -g=x -o -prune \) -o \
    -perm -o=x -o -prune \
  \) ! -type d -o -type l -o \
    -user 1 \( ! -perm -u=w -o -print \) -o \
    \( -group 1 -o -group 2 \) \( ! -perm -g=w -o -print \) -o \
    ! -perm -o=w -o -print

Ou pour un arbitraire $useret son appartenance au groupe récupéré de la base de données utilisateur:

groups=$(id -G "$user" | sed 's/ / -o -group /g'); IFS=" "
find / -type d \
  \( \
    -user "$user" \( -perm -u=x -o -prune \) -o \
    \( -group $groups \) \( -perm -g=x -o -prune \) -o \
    -perm -o=x -o -prune \
  \) ! -type d -o -type l -o \
    -user "$user" \( ! -perm -u=w -o -print \) -o \
    \( -group $groups \) \( ! -perm -g=w -o -print \) -o \
    ! -perm -o=w -o -print

(ce qui est 3 processus au total: id, sedet find)

Le mieux ici serait de descendre l'arborescence en tant que root et de vérifier les autorisations en tant qu'utilisateur pour chaque fichier.

 find / ! -type l -exec sudo -u "$user" sh -c '
   for file do
     [ -w "$file" ] && printf "%s\n" "$file"
   done' sh {} +

(c'est un findprocessus plus un sudoet shtraiter tous les quelques milliers de fichiers, [et printfsont généralement construits dans le shell).

Ou avec perl:

find / ! -type l -print0 |
  sudo -u "$user" perl -Mfiletest=access -l -0ne 'print if -w'

(3 procédés au total: find, sudoet perl).

Ou avec zsh:

files=(/**/*(D^@))
USERNAME=$user
for f ($files) {
  [ -w $f ] && print -r -- $f
}

(0 processus au total, mais stocke la liste complète des fichiers en mémoire)

Ces solutions reposent sur l' access(2)appel système. C'est au lieu de reproduire l'algorithme que le système utilise pour vérifier l'autorisation d'accès, nous demandons au système de faire cette vérification avec le même algorithme (qui prend en compte les autorisations, les ACL, les indicateurs immuables, les systèmes de fichiers en lecture seule ... ) qu'il utiliserait si vous essayez d'ouvrir le fichier pour l'écriture, c'est donc le plus proche que vous obtiendrez d'une solution fiable.

Pour tester les solutions données ici, avec les différentes combinaisons d'utilisateurs, de groupes et d'autorisations, vous pouvez faire:

perl -e '
  for $u (1,2) {
    for $g (1,2,3) {
      $d1="u${u}g$g"; mkdir$d1;
      for $m (0..511) {
        $d2=$d1.sprintf"/%03o",$m; mkdir $d2; chown $u, $g, $d2; chmod $m,$d2;
        for $uu (1,2) {
          for $gg (1,2,3) {
            $d3="$d2/u${uu}g$gg"; mkdir $d3;
            for $mm (0..511) {
              $f=$d3.sprintf"/%03o",$mm;
              open F, ">","$f"; close F;
              chown $uu, $gg, $f; chmod $mm, $f
            }
          }
        }
      }
    }
  }'

Faire varier l'utilisateur entre 1 et 2 et le groupe entre 1, 2 et 3 et nous limiter aux 9 bits inférieurs des autorisations car c'est déjà 9458694 fichiers créés. Cela pour les répertoires et encore pour les fichiers.

Cela crée toutes les combinaisons possibles de u<x>g<y>/<mode1>/u<z>g<w>/<mode2>. L'utilisateur avec uid 1 et gids 1 et 2 aurait un accès en écriture u2g1/010/u2g3/777mais pas u1g2/677/u1g1/777par exemple.

Maintenant, toutes ces solutions tentent d'identifier les chemins d'accès des fichiers que l'utilisateur peut ouvrir pour l'écriture, ce qui est différent des chemins d'accès par lesquels l'utilisateur peut modifier le contenu. Pour répondre à cette question plus générique, il y a plusieurs choses à prendre en compte:

1. $ user peut ne pas avoir accès en écriture à /a/b/filemais s'il en possède file(et a un accès de recherche à /a/b, et le système de fichiers n'est pas en lecture seule, et le fichier n'a pas l'indicateur immuable, et il a un accès shell au système), il serait alors en mesure de modifier les autorisations du fileet de s'accorder l'accès.
2. Même chose s'il possède /a/bmais n'a pas accès à la recherche.
3. $ user peut ne pas avoir accès à /a/b/filecar il n'a pas accès à la recherche de /aou /a/b, mais ce fichier peut avoir un lien dur à /b/c/filepar exemple, auquel cas il peut être en mesure de modifier le contenu de /a/b/fileen l'ouvrant via son /b/c/filechemin.
4. Même chose avec les fixations . Il n'a peut-être pas accès à la recherche /a, mais il /a/bpeut être monté en liaison/c , il peut donc ouvrir filepour écrire via son /c/fileautre chemin.
5. Il ne dispose peut-être pas d'autorisations d'écriture /a/b/file, mais s'il dispose d'un accès en écriture, /a/bil peut le supprimer ou le renommer fileet le remplacer par sa propre version. Il modifierait le contenu du fichier /a/b/filemême s'il s'agissait d'un fichier différent.
6. Même chose s'il a accès en écriture /a(il pourrait renommer /a/bà /a/c, créer un nouveau /a/brépertoire et une nouvelle fileen elle.

Trouver les chemins qui $userpourraient être modifiés. Pour adresser 1 ou 2, nous ne pouvons plus compter sur l' access(2)appel système. Nous pourrions ajuster notre find -permapproche pour supposer l'accès à la recherche aux répertoires, ou l'accès en écriture aux fichiers dès que vous en êtes le propriétaire:

groups=$(id -G "$user" | sed 's/ / -o -group /g'); IFS=" "
find / -type d \
  \( \
    -user "$user" -o \
    \( -group $groups \) \( -perm -g=x -o -prune \) -o \
    -perm -o=x -o -prune \
  \) ! -type d -o -type l -o \
    -user "$user" -print -o \
    \( -group $groups \) \( ! -perm -g=w -o -print \) -o \
    ! -perm -o=w -o -print

Nous pourrions aborder 3 et 4, en enregistrant les numéros de périphérique et d'inode ou tous les fichiers $ user a une autorisation d'écriture et rapporte tous les chemins de fichiers qui ont ces numéros de dev + inode. Cette fois, nous pouvons utiliser les access(2)approches plus fiables :

Quelque chose comme:

find / ! -type l -print0 |
  sudo -u "$user" perl -Mfiletest=access -0lne 'print 0+-w,$_' |
  perl -l -0ne '
    ($w,$p) = /(.)(.*)/;
    ($dev,$ino) = stat$p or next;
    $writable{"$dev,$ino"} = 1 if $w;
    push @{$p{"$dev,$ino"}}, $p;
    END {
      for $i (keys %writable) {
        for $p (@{$p{$i}}) {
          print $p;
        }
      }
    }'

5 et 6 sont à première vue compliqués par le tpeu des permissions. Lorsqu'il est appliqué sur des répertoires, c'est le bit de suppression restreint qui empêche les utilisateurs (autres que le propriétaire du répertoire) de supprimer ou de renommer les fichiers qu'ils ne possèdent pas (même s'ils ont un accès en écriture au répertoire).

Par exemple, si nous revenons à notre exemple précédent, si vous avez accès en écriture à /a, alors vous devriez être en mesure de renommer /a/bà /a/c, puis recréer un /a/brépertoire et un nouveau filelà - dedans. Mais si le tbit est activé /aet que vous ne le possédez pas /a, vous ne pouvez le faire que si vous le possédez /a/b. Ça donne:

• Si vous possédez un répertoire, conformément à 1, vous pouvez vous accorder un accès en écriture et le bit t ne s'applique pas (et vous pouvez le supprimer de toute façon), vous pouvez donc supprimer / renommer / recréer n'importe quel fichier ou répertoire dedans, donc tous les chemins de fichiers en dessous sont à vous de réécrire avec n'importe quel contenu.
• Si vous ne le possédez pas mais avez un accès en écriture, alors:
  • Soit le tbit n'est pas défini, et vous êtes dans le même cas que ci-dessus (tous les chemins d'accès aux fichiers vous appartiennent).
  • ou il est défini et vous ne pouvez pas modifier les fichiers que vous ne possédez pas ou auxquels vous n'avez pas accès en écriture.

Nous pouvons donc répondre à tous les 1, 2, 5 et 6 avec:

find / -type d \
  \( \
    -user "$user" -prune -exec find {} + -o \
    \( -group $groups \) \( -perm -g=x -o -prune \) -o \
    -perm -o=x -o -prune \
  \) ! -type d -o -type l -o \
    -user "$user" \( -type d -o -print \) -o \
    \( -group $groups \) \( ! -perm -g=w -o \
       -type d ! -perm -1000 -exec find {} + -o -print \) -o \
    ! -perm -o=w -o \
    -type d ! -perm -1000 -exec find {} + -o \
    -print

Cela et la solution pour 3 et 4 sont indépendants, vous pouvez fusionner leur sortie pour obtenir une liste complète:

{
  find / ! -type l -print0 |
    sudo -u "$user" perl -Mfiletest=access -0lne 'print 0+-w,$_' |
    perl -0lne '
      ($w,$p) = /(.)(.*)/;
      ($dev,$ino) = stat$p or next;
      $writable{"$dev,$ino"} = 1 if $w;
      push @{$p{"$dev,$ino"}}, $p;
      END {
        for $i (keys %writable) {
          for $p (@{$p{$i}}) {
            print $p;
          }
        }
      }'
  find / -type d \
    \( \
      -user "$user" -prune -exec sh -c 'exec find "$@" -print0' sh {} + -o \
      \( -group $groups \) \( -perm -g=x -o -prune \) -o \
      -perm -o=x -o -prune \
    \) ! -type d -o -type l -o \
      -user "$user" \( -type d -o -print0 \) -o \
      \( -group $groups \) \( ! -perm -g=w -o \
         -type d ! -perm -1000 -exec sh -c 'exec find "$@" -print0' sh {} + -o -print0 \) -o \
      ! -perm -o=w -o \
      -type d ! -perm -1000 -exec sh -c 'exec find "$@" -print0' sh {} + -o \
      -print0
} | perl -l -0ne 'print unless $seen{$_}++'

Comme cela doit être clair si vous avez tout lu jusqu'à présent, une partie au moins ne concerne que les autorisations et la propriété, pas les autres fonctionnalités qui peuvent accorder ou restreindre l'accès en écriture (FS en lecture seule, ACL, indicateur immuable, autres fonctionnalités de sécurité ...). Et comme nous les traitons en plusieurs étapes, certaines de ces informations peuvent être erronées si les fichiers / répertoires sont créés / supprimés / renommés ou leurs autorisations / propriété modifiées pendant l'exécution de ce script, comme sur un serveur de fichiers occupé avec des millions de fichiers .

Notes sur la portabilité

Tout ce code est standard (POSIX, Unix pour tbit) sauf:

• -print0est une extension GNU désormais également prise en charge par quelques autres implémentations. Avec les findimplémentations qui ne le prennent pas en charge, vous pouvez utiliser à la -exec printf '%s\0' {} +place et remplacer -exec sh -c 'exec find "$@" -print0' sh {} +par -exec sh -c 'exec find "$@" -exec printf "%s\0" {\} +' sh {} +.
• perln'est pas une commande spécifiée par POSIX mais est largement disponible. Vous avez besoin perl-5.6.0ou au-dessus pour -Mfiletest=access.
• zshn'est pas une commande spécifiée par POSIX. Ce zshcode ci-dessus devrait fonctionner avec zsh-3 (1995) et au-dessus.
• sudon'est pas une commande spécifiée par POSIX. Le code devrait fonctionner avec n'importe quelle version tant que la configuration du système permet de s'exécuter en perltant qu'utilisateur donné.

Vous pouvez combiner des options avec la findcommande, de sorte qu'il trouvera les fichiers avec le mode et le propriétaire spécifiés. Par exemple:

$ find / \( -group staff -o -group users \) -and -perm -g+w

La commande ci-dessus listera toutes les entrées qui appartiennent au groupe "staff" ou "users" et ont une autorisation d'écriture pour ce groupe.

Vous devez également vérifier les entrées qui appartiennent à votre utilisateur et les fichiers qui sont accessibles en écriture, donc:

$ find / \( -user yourusername -or \
             \(  \( -group staff -o -group users \) -and -perm -g+w \
             \) -or \
            -perm -o+w \
         \)

Cependant, cette commande ne correspondra pas aux entrées avec ACL étendue. Vous pourrez sudonc découvrir toutes les entrées accessibles en écriture:

# su - yourusername
$ find / -writable

L'approche dépend de ce que vous testez réellement.

1. Voulez-vous vous assurer que l' accès en écriture est possible?
2. Voulez-vous garantir le manque d'accès en écriture?

C'est parce qu'il y a tellement de façons d'arriver à 2) et la réponse de Stéphane les couvre bien (immuable est à retenir), et rappelez-vous qu'il existe également des moyens physiques, tels que démonter le lecteur ou le rendre en lecture seule à un niveau matériel (onglets de disquette). Je suppose que vos milliers de fichiers se trouvent dans des répertoires différents et que vous voulez un rapport ou que vous vérifiez une liste principale. (Un autre abus de Puppet ne fait qu'attendre).

Vous voulez probablement que l'arborescence perl de Stéphane et "joignent" la sortie avec une liste si nécessaire (su attrapera également l'exécution manquante sur les répertoires parents?). Si la maternité de substitution est un problème de performances, faites-vous cela pour un "grand nombre" d'utilisateurs? Ou s'agit-il d'une requête en ligne? S'il s'agit d'une exigence permanente permanente, il peut être temps d'envisager un produit tiers.

Tu peux faire...

find / ! -type d -exec tee -a {} + </dev/null

... pour une liste de tous les fichiers dans lesquels l'utilisateur ne peut pas écrire comme écrit dans stderr sous la forme ...

"tee: cannot access %s\n", <pathname>" 

...ou similaire.

Voir les commentaires ci-dessous pour des notes sur les problèmes que cette approche pourrait avoir, et l'explication ci-dessous pour savoir pourquoi cela pourrait fonctionner. Plus sainement, cependant, vous ne devriez probablement utiliser que find des fichiers normaux comme:

find / -type f -exec tee -a {} + </dev/null

En bref, teeaffichera des erreurs lors d'une tentative de open()fichier avec l'un des deux drapeaux ...

O_WRONLY

Ouvert pour l'écriture uniquement.

O_RDWR

Ouvert à la lecture et à l'écriture. Le résultat n'est pas défini si cet indicateur est appliqué à une FIFO.

... et rencontres ...

[EACCES]

L'autorisation de recherche est refusée sur un composant du préfixe de chemin, ou le fichier existe et les autorisations spécifiées par oflag sont refusées, ou le fichier n'existe pas et l'autorisation d'écriture est refusée pour le répertoire parent du fichier à créer, ou O_TRUNC est spécifié et l'autorisation d'écriture est refusée.

... comme spécifié ici :

L' teeutilitaire doit copier l'entrée standard sur la sortie standard, en effectuant une copie dans zéro ou plusieurs fichiers. L'utilitaire tee ne doit pas tamponner la sortie.

Si l' -aoption n'est pas spécifiée, les fichiers de sortie doivent être écrits (voir Lecture, écriture et création de fichiers ) ...

... POSIX.1-2008 nécessite des fonctionnalités équivalentes à l'utilisation de O_APPEND ...

Parce qu'il doit vérifier de la même manière test -wque ...

-w chemin

Vrai si le chemin d'accès se résout en une entrée de répertoire existante pour un fichier pour lequel l'autorisation d'écrire dans le fichier sera accordée, comme défini dans Lecture, Écriture et Création de fichier . False si le chemin d'accès ne peut pas être résolu, ou si le chemin d'accès se résout en une entrée de répertoire existante pour un fichier pour lequel l'autorisation d'écrire dans le fichier ne sera pas accordée.

Ils vérifient tous les deux EACCESS .