Path: ...!3.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!cleanfeed2-a.proxad.net!nnrp4-2.free.fr!not-for-mail Newsgroups: fr.comp.os.bsd X-Mozilla-News-Host: news://news.free.fr:119 From: Francois Lafont Subject: =?UTF-8?Q?Fichier_binaire_d=27un_daemon_writable_ssi_le_damon_est_s?= =?UTF-8?B?dG9wcMOp?= Date: Mon, 11 Jan 2021 20:33:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Lines: 121 Message-ID: <5ffca81a$0$6449$426a74cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 11 Jan 2021 20:33:46 CET NNTP-Posting-Host: 86.247.215.236 X-Trace: 1610393626 news-2.free.fr 6449 86.247.215.236:48280 X-Complaints-To: abuse@proxad.net Bytes: 5654 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