A côté d'umask, qu'est-ce qui affecte les permissions des nouveaux répertoires?

Question

J'ai remarqué que si vous interruptiez rsync, certains nouveaux répertoires conservent les permissions drwx------, bien que umask actuel soit 0022.

Je lancé gdb et essayé d'appeler explicitement umask(0) droit avant d'appeler mkdir(), mais il n'a eu aucun effet: j'attendre de nouveaux dirs avoir drwxrwxrwx, mais ils avaient encore drwx------.

(Dans les versions les plus récentes de rsync ils ne sont plus drwx------, mais toujours pas affecté par umask)

Si je change la commande à /bin/mkdir, appelant umask() commence à travailler. Il semble que rsync utilise de la magie.

Voici un script de test: (Pour une raison quelconque le point d'arrêt sur mkdir() ne fonctionne que lors de la copie de ssh)

(
rm -rf /tmp/3 && mkdir -p /tmp/3 && cd /tmp/3 && 
#gdb -q -nx --args /bin/mkdir foo <<EOF 
gdb -q -nx --args rsync -r --include=/profile.d --exclude="*" localhost:/etc/ ./ <<'EOF' 
set width 0 
set height 0 
set pagination no 
set breakpoint pending on 
b mkdir 
b mkdirat 
run 
del 
print (char*)$rdi 
call umask(0) 
call mkdir("test") 
fin 
shell ls -l 
p/o umask(0) 
k 
EOF 
) 

_

Reading symbols from /usr/bin/rsync...Reading symbols from /usr/bin/rsync...(no debugging symbols found)...done. 
(no debugging symbols found)...done. 
Missing separate debuginfos, use: debuginfo-install rsync-3.0.9-15.el7.x86_64 
(gdb) (gdb) (gdb) (gdb) (gdb) Breakpoint 1 at 0x6c70 
(gdb) Function "mkdirat" not defined. 
Breakpoint 2 (mkdirat) pending. 
(gdb) Starting program: /usr/bin/rsync -r --include=/profile.d --exclude=\* localhost:/etc/ ./ 
Detaching after fork from child process 15444. 
Detaching after fork from child process 15464. 

Breakpoint 1, 0x00007ffff76ee720 in mkdir() from /lib64/libc.so.6 
(gdb) Delete all breakpoints? (y or n) [answered Y; input not from terminal] 

argument de mkdir:

(gdb) $1 = 0x7fffffff9330 "profile.d" 

valeur umask précédente:

(gdb) $2 = 0 

résultat de mkdir("test")

(gdb) $3 = 0 

_

(gdb) Run till exit from #0 0x00007ffff76ee720 in mkdir() from /lib64/libc.so.6 
0x000055555556845f in recv_generator() 
(gdb) total 8 
drwx------ 2 il il 4096 Jan 28 20:02 profile.d 
drwx------ 2 il il 4096 Jan 28 20:02 test 
(gdb) $4 = 0 
(gdb) Kill the program being debugged? (y or n) [answered Y; input not from terminal] 
rsync: connection unexpectedly closed (31 bytes received so far) [sender] 
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9] 
(gdb) quit 
[il@basinsrv ~]$ rsync: connection unexpectedly closed (51 bytes received so far) [receiver] 
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [receiver=3.0.9] 

Answer 1

Les autorisations demandées lors de la création du répertoire sont masqués par le umask pour obtenir les autorisations finales.

Rsync utilise très probablement les autorisations du répertoire distant pour les appliquer au répertoire local. En outre, rsync peut définir les autorisations après la création du répertoire en utilisant l'appel système chmod() qui n'applique pas du tout l'umask.

Le paramètre umask est conçu pour autoriser les autorisations par défaut lors de la création de répertoires ou de fichiers sans définir spécifiquement les autorisations sur le fichier. La plupart des utilitaires simples qui créent des fichiers demandent simplement le mode d'autorisation 666 (perms pour tout le monde) et laissent l'umask le réduire.

NOTE également que l'utilisation de gdb peut ne pas fonctionner comme souhaité. GDB peut interrompre les appels de fonction dans l'espace utilisateur, mais pas sur les appels système. Essayez d'utiliser strace (si c'est Linux/Unix) - il montre tous les appels système comme ils sont faits (très, très pratique pour un cas comme celui-ci).