Bonjour à tous,
Attention, je préfère prévenir, je connais très mal le système BSD alors
désolé par avance si je passe à côté de choses basiques.
Voici le résumé de ma demande : j'ai un serveur FreeBSD 12.2-RC3 (plus
précisément c'est un serveur TrueNAS) sur lequel j'ai installé manuellement
un daemon correspondant à un fichier binaire qu'on appellera "b". Je suis
root sur la machine et, si j'en crois la sortie de « ls -l "b" », en tant que
root le fichier m'est parfaitement accessible en écriture. Pourtant, si je fais
un simple
if [ -w "$b" ]; then echo WRITABLE; else echo NOT-WRITABLE; fi
cela m'affichera :
1. NOT-WRITABLE si le daemon est en cours d'exécution.
2. WRITABLE si le daemon est stoppé.
Pourtant, dans les deux cas (que le daemon soit stoppé ou non), les permissions
Unix du fichier "b" restent totalement inchangées. De plus, dans les deux cas,
je suis parfaitement en mesure de faire un touch sur le fichier. Quel mécanisme
système de l'OS entraîne cette différence entre les deux cas (daemon stoppé ou
démarré) ?
---
Maintenant, voici les détails. Le fichier s'appelle
~# b=/usr/local/capsdrv/filer/bin/capsdrv
Voici les permissions :
~# ls -ld /usr /usr/local /usr/local/capsdrv /usr/local/capsdrv/filer /usr/local/capsdrv/filer/bin "$b"
drwxr-xr-x 13 root wheel 13 Dec 2 11:27 /usr
drwxr-xr-x 17 root wheel 18 Dec 2 14:05 /usr/local
drwxr-x--- 3 root wheel 3 Dec 2 14:05 /usr/local/capsdrv
drwxr-xr-x 5 root wheel 6 Jan 11 15:14 /usr/local/capsdrv/filer
drwxr-xr-x 2 root wheel 6 Jan 11 16:46 /usr/local/capsdrv/filer/bin
-rwxrw---- 1 root wheel 11057232 Jan 11 20:11 /usr/local/capsdrv/filer/bin/capsdrv
Voici le fichier qui m'a permis de faire de ce binaire un daemon :
~# cat /usr/local/etc/rc.d/capsdrv_filer
#!/bin/sh
# This file is managed by Ansible, don't edit it.
#
#
https://redbyte.eu/en/blog/supervised-freebsd-init-script-for-go-deamon/ # PROVIDE: capsdrv_filer
# REQUIRE: networking
# KEYWORD:
. /etc/rc.subr
. /usr/local/capsdrv/filer/etc/setenv.sh
name="capsdrv_filer"
rcvar="capsdrv_filer_enable"
goprogram_user="capsrdv"
goprogram_command="/usr/local/capsdrv/filer/bin/capsdrv -path /usr/local/capsdrv/filer/etc"
pidfile="/var/run/${name}.pid"
command="/usr/sbin/daemon"
command_args="-S -P ${pidfile} -r -f ${goprogram_command}"
load_rc_config $name
: ${goprogram_enable:=no}
run_rc_command "$1"
Le daemon est en train de tourner actuellement :
~# service capsdrv_filer status
capsdrv_filer is running as pid 16351.
Les deux tests suivants m'indiquent que le fichier n'est pas writable :
~# if [ -w "$b" ]; then echo WRITABLE; else echo NOT-WRITABLE; fi
NOT-WRITABLE
~# echo "import os; x = os.access('$b', os.W_OK); print(x)" | python
False
~# whoami # Et pourtant je suis root.
root
Déjà, à ce stade, je suis surpris car les tests me disent que le fichier
n'est pas writable alors que je suis root et que les permissions Unix semblent
me donner un accès en écriture à ce fichier. Mais ce qui suit me surprend
encore plus, si je stoppe le daemon, alors les choses changent ;
~# service capsdrv_filer stop
Stopping capsdrv_filer.
Waiting for PIDS: 16351.
~# ls -ld /usr /usr/local /usr/local/capsdrv /usr/local/capsdrv/filer /usr/local/capsdrv/filer/bin "$b"
drwxr-xr-x 13 root wheel 13 Dec 2 11:27 /usr
drwxr-xr-x 17 root wheel 18 Dec 2 14:05 /usr/local
drwxr-x--- 3 root wheel 3 Dec 2 14:05 /usr/local/capsdrv
drwxr-xr-x 5 root wheel 6 Jan 11 15:14 /usr/local/capsdrv/filer
drwxr-xr-x 2 root wheel 6 Jan 11 16:46 /usr/local/capsdrv/filer/bin
-rwxrw---- 1 root wheel 11057232 Jan 11 20:11 /usr/local/capsdrv/filer/bin/capsdrv
Absolument rien n'a changé au niveau des permissions Unix et pourtant :
~# if [ -w "$b" ]; then echo WRITABLE; else echo NOT-WRITABLE; fi
WRITABLE
~# echo "import os; x = os.access('$b', os.W_OK); print(x)" | python
True
Force est de constater qu'il y a un mécanisme système qui protège le
fichier en écriture lorsque le daemon est en cours d'exécution mais ce
mécanisme ne correspond pas aux permissions Unix classiques que je connais.
Mais quel est ce mécanisme ?
Merci d'avance pour votre aide.
-- François Lafont