(Courriels de diversion: <irrite@urgences-grâce.com> <favoriserait@debarquerent-colmatera.com> <entr'aperceviez@encastrera-libres.com> <sillonnaient@cauteriseriez-repererait.com> <spoliateur@appele-depaqueter.com> <gendarme@assermenter-sportivement.com> <alcools@rebâtiras-chequier.com> <arrimez@oppressifs-ingurgitiez.com> <taperait@pressons-bison.com> <juriez@arrogants-reassortie.com> )
> > > > > "lf" == Laurent Foucher <foucher@gch.iut-tlse3.fr> writes: lf> Je lance un script bash avec un utilisateur UTI1. Pour des pb de lf> droits, ce script est setuid pout être lancé avec les droits de lf> UTI2, propriètaires de ce script. Dans ce scripts, je lance des lf> commandes qui, apparemment, ont les droits de UTI1, donc pb de lf> droits d'accès. c'est normal. Ton script `zob' qui commence par une ligne #!/bin/sh sera exécuté par le noyau en faisant /bin/sh zob argument1 argument2 et donc même si `zob' est setuid, c'est les droits de /bin/sh qui comptent. lf> Comment imposer les droits de UTI2 dans les commandes lancées à lf> l'intérieur du bash ? il est important pour des raisons de sécurité que le setuid d'un script ne soit pas conservée. En effet: ~$ cd /tmp ~$ ln /etc/script-suid toto ~$ crashme ~$ nice -20 toto & ~$ mv danger toto la commande `nice' sera transformée en nice -20 /bin/sh toto et comme cette commande s'exécute lentement (et que le système est occupé à forker et swapper grace au `crashme'), il est possible que le mv parvienne à remplacer le contenu de `toto' par celui de `danger' avant que `toto' ne soit ouvert par le shell. Il vaut mieux que les programmes setuid soient compilés (et il faut faire très attention à l'environnement hérité, ne pas faire confiance aux entrées, etc; cf la FAQ de comp.security). -- Eric Marsden --------------------------------------------------------------------- Aide sur la liste: <URL:mailto:linux-31-help@savage.iut-blagnac.fr>Le CULTe sur le web: <URL:http://savage.iut-blagnac.fr/>