Tout est dans le titre. Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les fichiers de B. C'est le cas par exemple de /private/tmp.
Patrick -- Patrick Stadelmann
In article <df8aa16d.0402090150.570f494e@posting.google.com>,
herve.nospam@tiscali.fr (herve) wrote:
Salut,
Tout est dans le titre.
Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs
utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les
fichiers de B. C'est le cas par exemple de /private/tmp.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Tout est dans le titre. Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les fichiers de B. C'est le cas par exemple de /private/tmp.
Patrick -- Patrick Stadelmann
FiLH
Patrick Stadelmann writes:
In article , (herve) wrote:
Salut,
Tout est dans le titre. Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs Ben ce pauvre sticky bit il en aura vu de belle.
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui qui disait de garder le binaire en mémoire...
Par contre oui, ce bit permet le fonctionnement correct d'un répertoire /tmp
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> writes:
In article <df8aa16d.0402090150.570f494e@posting.google.com>,
herve.nospam@tiscali.fr (herve) wrote:
Salut,
Tout est dans le titre.
Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs
Ben ce pauvre sticky bit il en aura vu de belle.
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui
qui disait de garder le binaire en mémoire...
Par contre oui, ce bit permet le fonctionnement correct d'un
répertoire /tmp
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Tout est dans le titre. Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs Ben ce pauvre sticky bit il en aura vu de belle.
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui qui disait de garder le binaire en mémoire...
Par contre oui, ce bit permet le fonctionnement correct d'un répertoire /tmp
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Patrick Stadelmann
In article , FiLH wrote:
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui qui disait de garder le binaire en mémoire...
Ca n'est plus le cas d'après le man :
The sticky bit has no effect on executable files. All optimization on whether text images remain resident in memory is handled by the kernel's virtual memory system.
Par contre oui, ce bit permet le fonctionnement correct d'un répertoire /tmp
Qui est un "sticky directory", toujours d'après le man.
Patrick -- Patrick Stadelmann
In article <uxznbsttzq.fsf@enseirb.fr>, FiLH <filh@filh.org> wrote:
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui
qui disait de garder le binaire en mémoire...
Ca n'est plus le cas d'après le man :
The sticky bit has no effect on executable files. All optimization on
whether text images remain resident in memory is handled by the
kernel's virtual memory system.
Par contre oui, ce bit permet le fonctionnement correct d'un
répertoire /tmp
Qui est un "sticky directory", toujours d'après le man.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Si je me souviens bien le sticky bit, le bit qui colle, c'est celui qui disait de garder le binaire en mémoire...
Ca n'est plus le cas d'après le man :
The sticky bit has no effect on executable files. All optimization on whether text images remain resident in memory is handled by the kernel's virtual memory system.
Par contre oui, ce bit permet le fonctionnement correct d'un répertoire /tmp
Qui est un "sticky directory", toujours d'après le man.
Patrick -- Patrick Stadelmann
laurent.pertois
Patrick Stadelmann wrote:
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les fichiers de B. C'est le cas par exemple de /private/tmp.
Et, plus accessible aux utilisateurs de Mac OS X courants, /Users/Shared.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs
utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les
fichiers de B. C'est le cas par exemple de /private/tmp.
Et, plus accessible aux utilisateurs de Mac OS X courants,
/Users/Shared.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
C'est le "sticky bit", utilisé pour les dossiers ou plusieurs utilisateurs doivent pouvoir lire et écrire : ça empêche A d'effacer les fichiers de B. C'est le cas par exemple de /private/tmp.
Et, plus accessible aux utilisateurs de Mac OS X courants, /Users/Shared.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Éric Lévénez
Le 9/02/04 10:50, dans , « herve » a écrit :
Tout est dans le titre.
Un ancien d'AOL ?
Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Le bit t sur un exécutable était utilisé il y a 25/30 ans, quand les accès aux disques étaient lents et que la mémoire virtuelle n'était pas au top. Une fois le programme terminé, au lieu de libérer la RAM, le code restait en mémoire. Cela accélérait les choses si on relançait le programme (le programme était déjà chargé). Aujourd'hui ce n'est plus utilisé car le système gère mieux les accès disque en utilisant un cache mémoire dans sa gestion de la mémoire virtuelle.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/02/04 10:50, dans <df8aa16d.0402090150.570f494e@posting.google.com>,
« herve » <herve.nospam@tiscali.fr> a écrit :
Tout est dans le titre.
Un ancien d'AOL ?
Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans
celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer
des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que
ses propres fichiers. Le bit t est typiquement appliqué aux répertoires
partagés par plusieurs utilisateurs.
Le bit t sur un exécutable était utilisé il y a 25/30 ans, quand les accès
aux disques étaient lents et que la mémoire virtuelle n'était pas au top.
Une fois le programme terminé, au lieu de libérer la RAM, le code restait en
mémoire. Cela accélérait les choses si on relançait le programme (le
programme était déjà chargé). Aujourd'hui ce n'est plus utilisé car le
système gère mieux les accès disque en utilisant un cache mémoire dans sa
gestion de la mémoire virtuelle.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je ne connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Le bit t sur un exécutable était utilisé il y a 25/30 ans, quand les accès aux disques étaient lents et que la mémoire virtuelle n'était pas au top. Une fois le programme terminé, au lieu de libérer la RAM, le code restait en mémoire. Cela accélérait les choses si on relançait le programme (le programme était déjà chargé). Aujourd'hui ce n'est plus utilisé car le système gère mieux les accès disque en utilisant un cache mémoire dans sa gestion de la mémoire virtuelle.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
patrick.noXmail.esnault
Éric Lévénez wrote: e connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Je cherche un équivalent Win NT bien pratique que je n'ai pas sur OSX : J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Cette fonction existe sous NT (lire, écrire et pas modifier) mais je n'ai pas trouvé d'équivalent sous OS X.
Ce "t" est-il une solution ? Batchmod ne le gère pas !
Éric Lévénez <news@levenez.com> wrote:
e connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans
celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer
des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que
ses propres fichiers. Le bit t est typiquement appliqué aux répertoires
partagés par plusieurs utilisateurs.
Je cherche un équivalent Win NT bien pratique que je n'ai pas sur OSX :
J'ai des dossiers très importants (des plans) chaque dessinateur peut
stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas
pouvoir détruire (par bétise ou malveilance) les plans existants.
Cette fonction existe sous NT (lire, écrire et pas modifier) mais je
n'ai pas trouvé d'équivalent sous OS X.
Ce "t" est-il une solution ?
Batchmod ne le gère pas !
Éric Lévénez wrote: e connaissais que r, w, x et - comme valeurs possibles des droits.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Je cherche un équivalent Win NT bien pratique que je n'ai pas sur OSX : J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Cette fonction existe sous NT (lire, écrire et pas modifier) mais je n'ai pas trouvé d'équivalent sous OS X.
Ce "t" est-il une solution ? Batchmod ne le gère pas !
jpnoSPAMuet
Patrick ESNAULT wrote:
J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Et en utilisant le dossier "Partagé" ?
-- JPN On me mèle sans les majuscules
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
J'ai des dossiers très importants (des plans) chaque dessinateur peut
stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas
pouvoir détruire (par bétise ou malveilance) les plans existants.
J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Et en utilisant le dossier "Partagé" ?
-- JPN On me mèle sans les majuscules
Éric Lévénez
Le 9/02/04 18:17, dans <1g8wikr.r787mhbysmuyN%, « Patrick ESNAULT » a écrit :
J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Si le fichier est avec un mode 666 (rw-rw-rw) tout le monde peut y lire/écrire. Si le mode est 644 (rw-r-r), alors seul le propriétaire peut y écrire, les autres ne peuvent que le lire.
Si le fichier est dans un répertoire avec le bit t, seul le propriétaire du fichier pourra l'effacer (sinon tout le monde avant accès au fichier en écriture le pourra).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/02/04 18:17, dans
<1g8wikr.r787mhbysmuyN%patrick.noXmail.esnault@cfd.noXmail.fr>, « Patrick
ESNAULT » <patrick.noXmail.esnault@cfd.noXmail.fr> a écrit :
J'ai des dossiers très importants (des plans) chaque dessinateur peut
stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas
pouvoir détruire (par bétise ou malveilance) les plans existants.
Si le fichier est avec un mode 666 (rw-rw-rw) tout le monde peut y
lire/écrire. Si le mode est 644 (rw-r-r), alors seul le propriétaire peut y
écrire, les autres ne peuvent que le lire.
Si le fichier est dans un répertoire avec le bit t, seul le propriétaire du
fichier pourra l'effacer (sinon tout le monde avant accès au fichier en
écriture le pourra).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 9/02/04 18:17, dans <1g8wikr.r787mhbysmuyN%, « Patrick ESNAULT » a écrit :
J'ai des dossiers très importants (des plans) chaque dessinateur peut stocker des nouveaux plans ou lire les anciens. Mais il ne doit pas pouvoir détruire (par bétise ou malveilance) les plans existants.
Si le fichier est avec un mode 666 (rw-rw-rw) tout le monde peut y lire/écrire. Si le mode est 644 (rw-r-r), alors seul le propriétaire peut y écrire, les autres ne peuvent que le lire.
Si le fichier est dans un répertoire avec le bit t, seul le propriétaire du fichier pourra l'effacer (sinon tout le monde avant accès au fichier en écriture le pourra).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
herve.nospam
Éric Lévénez wrote in message news:<BC4D73AB.68747%...
Le 9/02/04 10:50, dans , Un ancien d'AOL ?
Pas tu tout, mais il m'a semblé inutile de répéter dans mon message le titre de celui-ci.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Merci pour ton explication détaillée (comme d'habitude ;-). J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon", réponse : chmod: invalid mode string: `rwxrwxrwt' Ca se change donc autrement...
Hervé
Éric Lévénez <news@levenez.com> wrote in message news:<BC4D73AB.68747%news@levenez.com>...
Le 9/02/04 10:50, dans <df8aa16d.0402090150.570f494e@posting.google.com>,
Un ancien d'AOL ?
Pas tu tout, mais il m'a semblé inutile de répéter dans mon message le
titre de celui-ci.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans
celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer
des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que
ses propres fichiers. Le bit t est typiquement appliqué aux répertoires
partagés par plusieurs utilisateurs.
Merci pour ton explication détaillée (comme d'habitude ;-).
J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon",
réponse :
chmod: invalid mode string: `rwxrwxrwt'
Ca se change donc autrement...
Éric Lévénez wrote in message news:<BC4D73AB.68747%...
Le 9/02/04 10:50, dans , Un ancien d'AOL ?
Pas tu tout, mais il m'a semblé inutile de répéter dans mon message le titre de celui-ci.
Sans le t sur un répertoire, toute personne peut effacer tout fichier dans celui-ci si elle a les droits d'écriture sur ce répertoire (on peut effacer des fichiers qui ne sont pas à soit). Avec le bit t, on ne peut effacer que ses propres fichiers. Le bit t est typiquement appliqué aux répertoires partagés par plusieurs utilisateurs.
Merci pour ton explication détaillée (comme d'habitude ;-). J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon", réponse : chmod: invalid mode string: `rwxrwxrwt' Ca se change donc autrement...
Hervé
Saïd
herve :
J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon", réponse : chmod: invalid mode string: `rwxrwxrwt' Ca se change donc autrement...
c'est plutot chmod +t bidon (contrairement à r, w ou x le bit t est unique i.e il n'y a pas de bit t pour le groupe un autre pour l'utilisateur et un pour le reste du monde).
-- Saïd.
herve :
J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon",
réponse :
chmod: invalid mode string: `rwxrwxrwt'
Ca se change donc autrement...
c'est plutot
chmod +t bidon
(contrairement à r, w ou x le bit t est unique i.e il n'y a pas de bit t
pour le groupe un autre pour l'utilisateur et un pour le reste du monde).
J'ai essayé sur un répertoire bidon un "chmod rwxrwxrwt bidon", réponse : chmod: invalid mode string: `rwxrwxrwt' Ca se change donc autrement...
c'est plutot chmod +t bidon (contrairement à r, w ou x le bit t est unique i.e il n'y a pas de bit t pour le groupe un autre pour l'utilisateur et un pour le reste du monde).
