Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
laurent.pertois
Jean-Yves Bernier wrote:
Laurent Pertois wrote:
Perso, j'aurais ajouté user1 et user2 dans le groupe machin. faut bien soit modifier le umask (cf google et ce groupe pour les
umask est la valeur par défaut des permissions, si j'ai bien compris. Je ne vois pas comment il pourra changer le GID du fichier.
Oui.
Clairement Mac OS X client n'a pas été adapté à ce petit jeu
Ce ne me semble pas capillotracté. Users et groupe sont quand même la base des protections Unix. Tout le monde récite "user group others" le premier jour. Je me sers d'OSX pour collaborer à plusieurs sur un même projet, il est essentiel que quelqu'un puisse venir chercher un fichier chez moi même si je n'ai pas pensé à le chowner avant de partir.
Chgrper, ça suffira. Surtout que pour chowner, seul root peut le faire (ou un admin avec sudo). Mais, que se passe-t-il sur les autres unix quand on fait des groupes, est-ce que les fichiers appartiennent au groupe principal de l'utilisateur ou au groupe du dossier ?
De plus, il faut peut-être jeter un oeil sur les sticky bits.
C'est bien pour ça que les groupes ont été faits, non?
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X Server, jamais sur les clients eux-mêmes, en fait.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Perso, j'aurais ajouté user1 et user2 dans le groupe machin.
faut bien soit modifier le umask (cf google et ce groupe pour les
umask est la valeur par défaut des permissions, si j'ai bien compris.
Je ne vois pas comment il pourra changer le GID du fichier.
Oui.
Clairement Mac OS X client n'a pas été adapté à ce petit jeu
Ce ne me semble pas capillotracté. Users et groupe sont quand même
la base des protections Unix. Tout le monde récite "user group others"
le premier jour. Je me sers d'OSX pour collaborer à plusieurs sur un
même projet, il est essentiel que quelqu'un puisse venir chercher un
fichier chez moi même si je n'ai pas pensé à le chowner avant de partir.
Chgrper, ça suffira. Surtout que pour chowner, seul root peut le faire
(ou un admin avec sudo). Mais, que se passe-t-il sur les autres unix
quand on fait des groupes, est-ce que les fichiers appartiennent au
groupe principal de l'utilisateur ou au groupe du dossier ?
De plus, il faut peut-être jeter un oeil sur les sticky bits.
C'est bien pour ça que les groupes ont été faits, non?
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X
Server, jamais sur les clients eux-mêmes, en fait.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Perso, j'aurais ajouté user1 et user2 dans le groupe machin. faut bien soit modifier le umask (cf google et ce groupe pour les
umask est la valeur par défaut des permissions, si j'ai bien compris. Je ne vois pas comment il pourra changer le GID du fichier.
Oui.
Clairement Mac OS X client n'a pas été adapté à ce petit jeu
Ce ne me semble pas capillotracté. Users et groupe sont quand même la base des protections Unix. Tout le monde récite "user group others" le premier jour. Je me sers d'OSX pour collaborer à plusieurs sur un même projet, il est essentiel que quelqu'un puisse venir chercher un fichier chez moi même si je n'ai pas pensé à le chowner avant de partir.
Chgrper, ça suffira. Surtout que pour chowner, seul root peut le faire (ou un admin avec sudo). Mais, que se passe-t-il sur les autres unix quand on fait des groupes, est-ce que les fichiers appartiennent au groupe principal de l'utilisateur ou au groupe du dossier ?
De plus, il faut peut-être jeter un oeil sur les sticky bits.
C'est bien pour ça que les groupes ont été faits, non?
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X Server, jamais sur les clients eux-mêmes, en fait.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Gerald
Jean-Yves Bernier wrote:
Je me demande comment fait Madame quand Monsieur a laissé la déclaration d'impôts dans son $HOME alors qu'il est en voyage et que la date limite est ce soir, si ils n'ont pas crée le groupe (Monsieur, Madame).
Ou alors, tout le monde travaille dans Shared et c'est le bordel.
C'est marrant je me suis posé exactement le même problème il y a quelques temps sans trouver de solution satisfaisante (Shared, où chacun garde *ses* autorisations est une terrible source d'énervement amha).
Sans avoir été plus loin dans le test, il me semble qu'une solution conviviale et simple serait de créer des groupes de travail virtuels dans PureFTPD Manager : interface graphique très mac, auteur de très bon esprit, existence d'un désinstalleur indépendant, création de "users" virtuels dans un groupe non vu par "lire les informations"... (mais bien vu, évidemment par Gestionnaire Netinfo). Un groupe par projet, quoi... pour en savoir plus : <http://jeanmatthieu.free.fr/pureftpd/index.html?http&&&jeanmatthieu.fre e.fr/pureftpd/download.html>
hth, -- Gérald
Jean-Yves Bernier <grokub@pescadoo.net> wrote:
Je me demande comment fait Madame quand Monsieur a laissé la déclaration
d'impôts dans son $HOME alors qu'il est en voyage et que la date limite
est ce soir, si ils n'ont pas crée le groupe (Monsieur, Madame).
Ou alors, tout le monde travaille dans Shared et c'est le bordel.
C'est marrant je me suis posé exactement le même problème il y a
quelques temps sans trouver de solution satisfaisante (Shared, où chacun
garde *ses* autorisations est une terrible source d'énervement amha).
Sans avoir été plus loin dans le test, il me semble qu'une solution
conviviale et simple serait de créer des groupes de travail virtuels
dans PureFTPD Manager : interface graphique très mac, auteur de très bon
esprit, existence d'un désinstalleur indépendant, création de "users"
virtuels dans un groupe non vu par "lire les informations"... (mais bien
vu, évidemment par Gestionnaire Netinfo). Un groupe par projet, quoi...
pour en savoir plus :
<http://jeanmatthieu.free.fr/pureftpd/index.html?http&&&jeanmatthieu.fre
e.fr/pureftpd/download.html>
Je me demande comment fait Madame quand Monsieur a laissé la déclaration d'impôts dans son $HOME alors qu'il est en voyage et que la date limite est ce soir, si ils n'ont pas crée le groupe (Monsieur, Madame).
Ou alors, tout le monde travaille dans Shared et c'est le bordel.
C'est marrant je me suis posé exactement le même problème il y a quelques temps sans trouver de solution satisfaisante (Shared, où chacun garde *ses* autorisations est une terrible source d'énervement amha).
Sans avoir été plus loin dans le test, il me semble qu'une solution conviviale et simple serait de créer des groupes de travail virtuels dans PureFTPD Manager : interface graphique très mac, auteur de très bon esprit, existence d'un désinstalleur indépendant, création de "users" virtuels dans un groupe non vu par "lire les informations"... (mais bien vu, évidemment par Gestionnaire Netinfo). Un groupe par projet, quoi... pour en savoir plus : <http://jeanmatthieu.free.fr/pureftpd/index.html?http&&&jeanmatthieu.fre e.fr/pureftpd/download.html>
hth, -- Gérald
laurent.pertois
Jean-Yves Bernier wrote:
Laurent Pertois wrote:
Mais, que se passe-t-il sur les autres unix quand on fait des groupes, est-ce que les fichiers appartiennent au groupe principal de l'utilisateur ou au groupe du dossier ?
Pour ce que j'en sais (assez peu), le fichier reçoit le groupe attribué au login, soit le gid principal. Il n'y a pas d'héritage.
http://marc.perkel.com/archives/000713.html
Alors pourquoi serait-ce différent sur Mac OS X ?
Unix has no mechanism for permission inheritence within the file system. Under netware when a user or group is given permissions to a folder - those permission apply by default to all files and directories under that folder. In Unix - if I create a file in someone else's directories I have to run chown on it to give that person permission to access it. Under Netware - or Windows - they already have those permissions.
Ce sont les ACL qui permettent de définir des héritages. Cela dit, les groupes me semblent suffisants pour ce que je veux faire. C'est juste Netinfo qui est un peu troublant.
NetInfo n'est qu'un stockage comme les flat files sur un BSD, c'est différent mais le but est le même.
- Le GID dans le record user définit son groupe principal dont le nom est donné par le record group de même GID (il m'est arrivé que ce record n'existe pas en transportant des users, les fichiers apparaissent alors user:unknown, il suffit de créer le groupe pour que unknown soit remplacé par son nom).
C'est normal, quand tu fais un ls -l (ou un pomme-i) on te fait une transcription des UID et GID en nom, si un UID ou un GID est introuvable, il est remplacé par unknown (ce qui est vrai en plus, c'est un UID/GID inconnu). Si tu le crées, hop, le mappage peut se faire. Fais un ls -ln et tu verras la réalité.
- La liste 'users' dans le record group permet de donner à des users accès à d'autres groupes que le sien. On a donc, si j'ai bien compris:
Equivalent d'une ligne dans /etc/groups.
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X Server, jamais sur les clients eux-mêmes, en fait.
Heu... la notion d'un "Unix client" est assez drôle.
:-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Mais, que se passe-t-il sur les autres unix quand on fait des groupes,
est-ce que les fichiers appartiennent au groupe principal de l'utilisateur
ou au groupe du dossier ?
Pour ce que j'en sais (assez peu), le fichier reçoit le groupe attribué
au login, soit le gid principal. Il n'y a pas d'héritage.
http://marc.perkel.com/archives/000713.html
Alors pourquoi serait-ce différent sur Mac OS X ?
Unix has no mechanism for permission inheritence within the file system.
Under netware when a user or group is given permissions to a folder -
those permission apply by default to all files and directories under that
folder. In Unix - if I create a file in someone else's directories I have
to run chown on it to give that person permission to access it. Under
Netware - or Windows - they already have those permissions.
Ce sont les ACL qui permettent de définir des héritages. Cela dit, les
groupes me semblent suffisants pour ce que je veux faire. C'est juste
Netinfo qui est un peu troublant.
NetInfo n'est qu'un stockage comme les flat files sur un BSD, c'est
différent mais le but est le même.
- Le GID dans le record user définit son groupe principal dont le nom
est donné par le record group de même GID (il m'est arrivé que ce record
n'existe pas en transportant des users, les fichiers apparaissent alors
user:unknown, il suffit de créer le groupe pour que unknown soit
remplacé par son nom).
C'est normal, quand tu fais un ls -l (ou un pomme-i) on te fait une
transcription des UID et GID en nom, si un UID ou un GID est
introuvable, il est remplacé par unknown (ce qui est vrai en plus, c'est
un UID/GID inconnu). Si tu le crées, hop, le mappage peut se faire. Fais
un ls -ln et tu verras la réalité.
- La liste 'users' dans le record group permet de donner à des users
accès à d'autres groupes que le sien. On a donc, si j'ai bien compris:
Equivalent d'une ligne dans /etc/groups.
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X
Server, jamais sur les clients eux-mêmes, en fait.
Heu... la notion d'un "Unix client" est assez drôle.
:-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais, que se passe-t-il sur les autres unix quand on fait des groupes, est-ce que les fichiers appartiennent au groupe principal de l'utilisateur ou au groupe du dossier ?
Pour ce que j'en sais (assez peu), le fichier reçoit le groupe attribué au login, soit le gid principal. Il n'y a pas d'héritage.
http://marc.perkel.com/archives/000713.html
Alors pourquoi serait-ce différent sur Mac OS X ?
Unix has no mechanism for permission inheritence within the file system. Under netware when a user or group is given permissions to a folder - those permission apply by default to all files and directories under that folder. In Unix - if I create a file in someone else's directories I have to run chown on it to give that person permission to access it. Under Netware - or Windows - they already have those permissions.
Ce sont les ACL qui permettent de définir des héritages. Cela dit, les groupes me semblent suffisants pour ce que je veux faire. C'est juste Netinfo qui est un peu troublant.
NetInfo n'est qu'un stockage comme les flat files sur un BSD, c'est différent mais le but est le même.
- Le GID dans le record user définit son groupe principal dont le nom est donné par le record group de même GID (il m'est arrivé que ce record n'existe pas en transportant des users, les fichiers apparaissent alors user:unknown, il suffit de créer le groupe pour que unknown soit remplacé par son nom).
C'est normal, quand tu fais un ls -l (ou un pomme-i) on te fait une transcription des UID et GID en nom, si un UID ou un GID est introuvable, il est remplacé par unknown (ce qui est vrai en plus, c'est un UID/GID inconnu). Si tu le crées, hop, le mappage peut se faire. Fais un ls -ln et tu verras la réalité.
- La liste 'users' dans le record group permet de donner à des users accès à d'autres groupes que le sien. On a donc, si j'ai bien compris:
Equivalent d'une ligne dans /etc/groups.
Oui. Mais je ne m'en sers que sur les partages de fichiers de Mac OS X Server, jamais sur les clients eux-mêmes, en fait.
Heu... la notion d'un "Unix client" est assez drôle.
:-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Jean-Yves Bernier wrote:
Et hop! Voila que tu passes en 1 seconde du Finder rose-bonbon au Finder qui te permet d'éditer .bash_profile sous BBEdit.
Tu vas me dire que tu as d'autres utilisations pour ce script, mais BBEdit permet d'ouvrir directement les fichiers invisibles sans les rendre visibles dans le Finder, pourtant.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jean-Yves Bernier <grokub@pescadoo.net> wrote:
Et hop! Voila que tu passes en 1 seconde du Finder rose-bonbon au Finder
qui te permet d'éditer .bash_profile sous BBEdit.
Tu vas me dire que tu as d'autres utilisations pour ce script, mais
BBEdit permet d'ouvrir directement les fichiers invisibles sans les
rendre visibles dans le Finder, pourtant.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Et hop! Voila que tu passes en 1 seconde du Finder rose-bonbon au Finder qui te permet d'éditer .bash_profile sous BBEdit.
Tu vas me dire que tu as d'autres utilisations pour ce script, mais BBEdit permet d'ouvrir directement les fichiers invisibles sans les rendre visibles dans le Finder, pourtant.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
