(Courriels de diversion: <destines@presentez-orthographieraient.com> <interviendrions@abuserais-cingleront.com> <desires@pauperisons-renseignant.com> <reelirions@ressassait-ânonnent.com> <necessaire@humecterait-flouerais.com> <illusionnes@inversaient-contribuons.com> <entravait@racheterent-crasse.com> <vissais@confrontez-croquiez.com> <deferente@denicheras-petarader.com> <predilections@mi-voix-thesauriserais.com> )
Eric Marsden tchatche...
>
> > > > > > "tb" == thierry <thierry@123immo.com> writes:>
> il est clair qu'il faut locker /etc/passwd (ou le cas échéant
> /etc/shadow).
locker le fichier ou 'serialiser' les acces, c'est ma conclusion.
j'ai lu les sources de adduser,useradd,newuser et machin bidules:
aucuns ne "locke" et un seul a le courage d'avouer que c'est par
flemme, et que de toute facon, ya un seul root, et qu'il peut
pas faire 36 choses a la fois...
> Avec la glibc et les dérivés SRV4 voir les fonctions
> lckpwdf(3) et ulckpwdf(3) déclarés dans <shadow.h> ;r
[thierry@viper thierry]$ man lckpwdfNo manual entry for lckpwdf
-> UTSL... c'est bien dans la glibc ?
> sinon il faut
> voir quel est le type de lockage utilisé par passwd, adduser et
> compagnie -- probablement flock ou lockf -- et faire pareil.
>
ah... donc rien faire, c'est bon aussi. Ou alors, il
faudra que j'aille chercher chez *BSD ?-)
> existants, éventuellement en les scriptant via expect ou Expect.pm.
>
Si ils le lockent pas, c,a sert a rien de les utiliser quand tu n'est
pas sur de la non-concurrence de ton probleme.
>
> avec Debian c'est très simple:
fouiller sunsite, c'est pas mal non plus
> inférieures c'est peut-être moins évident :-)
>
{{{Minix#rUl3z}}}
Bonne continuation.
---------------------------------------------------------------------
Aide sur la liste: <URL:mailto:linux-31-help@savage.iut-blagnac.fr>Le CULTe sur le web: <URL:http://savage.iut-blagnac.fr/>