Discussion :

[devilfish]

Bonjour,
Je développe actuellement un programme en C et je rencontre un problème concernant l'envoi d'un signal d'un processus à un autre.

Un premier programme (appelé host) tourne en tant que démon sous l'utilisateur nobody.
A un moment il fait un fork() puis un execve() vers un autre programme (appelé run_interface) dont le setuid bit est activé. Le propriétaire de run_interface n'est pas root mais un utilisateur normal (appelons le user).
Au lancement de run_interface, la situation est donc la suivante concernant les uid du processus run_interface:
uid réel = uid de nobody
uid effectif = uid de user
uid sauvé = uid de user

j'utilise ensuite la fonction setresuid() pour obtenir la configuration suivante:
uid réel = uid de user
uid effectif = uid de user
uid sauvé = uid de nobody

Le problème est que lorsque host envoie un signal avec la fonction kill() l'appel échoue avec l'erreur EPERM.
Pourtant la page man de kill précise:
For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process
Et je suis bien dans le cas ou l'uid réel du processus appellent est égal à l'uid sauvé du processus cible.
Je précise que si je laisse la configuration initiale (avant le setresuid()) l'envoi du signal fonctionne sans problème.
Est-ce que quelqu'un a déjà rencontré un problème similaire?
Merci

Distribution: Red Hat Entreprise Linux 5

[Sve@r]

Bonjour,
Je développe actuellement un programme en C et je rencontre un problème concernant l'envoi d'un signal d'un processus à un autre.

Un premier programme (appelé host) tourne en tant que démon sous l'utilisateur nobody.
A un moment il fait un fork() puis un execve() vers un autre programme (appelé run_interface) dont le setuid bit est activé. Le propriétaire de run_interface n'est pas root mais un utilisateur normal (appelons le user).
Au lancement de run_interface, la situation est donc la suivante concernant les uid du processus run_interface:
uid réel = uid de nobody
uid effectif = uid de user
uid sauvé = uid de user

j'utilise ensuite la fonction setresuid() pour obtenir la configuration suivante:
uid réel = uid de user
uid effectif = uid de user
uid sauvé = uid de nobody

Le problème est que lorsque host envoie un signal avec la fonction kill() l'appel échoue avec l'erreur EPERM.
Pourtant la page man de kill précise:
For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process
Et je suis bien dans le cas ou l'uid réel du processus appellent est égal à l'uid sauvé du processus cible.

Ben non. Le uid de ton host c'est nobody. Et le uid de ton run_interface c'est user. Et nobody n'a pas le droit d'envoyer un kill à un processus possédé par "user"...
Bon personnellement je ne me suis jamais penché sur les différents user. Qu'est-ce qu'a le droit de faire le réel, l'effectif, le sauvé (d'ailleurs lui je ne le connaissais pas). Ce que je sais, c'est qu'une fois j'ai tenté de faire un setuid à l'envers et ça n'a pas marché.
Je m'explique: j'avais un fichier appartenant à "user" et droits 007. Ainsi "user" ne pouvait pas le lire.
J'ai créé un programme appartenant à nobody et je lui ai mis le setuid. Puis j'ai demandé au programme de lire le fichier. Mon idée était que le processus appartenant à nobody n'étant pas user, les droits utilisés seraient ceux de other (rwx). Ben ça n'a pas marché. Qqpart, le uid réel devait avoir une importance dans cet accès. Ben je pense qu'il s'agit de la même chose pour toi. Qqpart, le uid réel "nobody" ne peut pas envoyer de kill à un procesuss uid "user"...

[devilfish]

Et nobody n'a pas le droit d'envoyer un kill à un processus possédé par "user"...

Ca parait logique en effet mais:
For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process
Le processus cible est bien possédé par user mais le fait que son uid sauvé soit nobody devrait permettre l'envoi d'un signal depuis nobody.
Il est vrai que les conditions sur les uid pour envoyer un signal semblent varier selon les distributions: http://unixpapa.com/incnote/setuid.html

[Sve@r]

Il est vrai que les conditions sur les uid pour envoyer un signal semblent varier selon les distributions: http://unixpapa.com/incnote/setuid.html

Joli - Je ne connaissais pas ces subtilités.

Maintenant tu constates que ton idée s'aventure aux limites de ce qui est autorisé et que même si ça marche sur ta plateforme, ce n'est pas portable.
Peut-être peux-tu remonter en amont et réfléchir sur les raisons qui font que ton processus fils change de uid...

[devilfish]

même si ça marche sur ta plateforme, ce n'est pas portable

En effet mais le programme est destiné à être utilisé uniquement sur red had donc ce n'est pas un problème essentiel.

Peut-être peux-tu remonter en amont et réfléchir sur les raisons qui font que ton processus fils change de uid...

Le programme run_interface est destiné à prendre l'identité de user avant de faire un execve vers un autre programme. Seulement le programme en question peut avoir été compilé sur une red hat 5 ou une red hat 4 et le programme host peut lui aussi tourner sur une red hat 5 ou une red hat 4.
Le problème se pose lorsque la compilation du programme a été effectuée sous red hat 5 et que l'hote tourne sous red hat 4. J'obtiens alors le message suivant:

relocation error: /lib64/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

juste après le execve et ce problème disparait lorsque je fixe l'uid réel à user (pourquoi? aucune idée).
En revanche si l'host tourne sur red hat 5 il n'y a pas de problème.

Je précise que j'utilise ldd pour repérer et copier tous les .so que le programme utilise donc ce n'est pas un problème de version des librairies sous red hat 4.