chmod ne peut pas changer l'autorisation du groupe sur Cygwin
J'utilise Cygwin et j'essaie de modifier l'autorisation d'accès au groupe avec chmod , par exemple.
$ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
$ chmod g= id_rsa
$ ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
Mais ça ne marche pas. Je peux changer l'autorisation pour l'utilisateur et les autres. Semble-t-il que le niveau de permission du groupe conserve en quelque sorte la même chose que celui de l'utilisateur?
J'avais un problème similaire à vous et j'utilisais le système de fichiers NTFS. La réponse de Keith Thompson ne m'a donc pas résolu le problème.
J'ai remplacé le propriétaire du groupe de fichiers par le groupe Users:
chown :Users filename
Après cela, j’ai été en mesure de modifier les autorisations du groupe selon ma volonté en utilisant chmod. Dans mon cas, puisqu'il s'agissait d'une clé RSA pour OpenSSH, j'ai:
chmod 700 filename
Et ça a fonctionné. Dans Cygwin, vous obtenez deux groupes par défaut, le groupe Root et le groupe Users. Je voulais ajouter un autre groupe, mais je ne pouvais pas le faire avec les outils que j'utilisais sous Linux. Pour cette raison, je viens d'utiliser le groupe Users.
Cygwin n'aime pas que les fichiers soient la propriété de groupes qu'il ne connaisse pas . Malheureusement, cela se produit assez souvent dans Cygwin, en particulier si votre PC est dans un domaine Windows où les choses changent constamment . Je synchronise aussi mes fichiers entre deux PC, via un lecteur externe, et les uids/gids sont différents d’un PC à l’autre, c’est donc une source de problèmes.
Si vous utilisez ls -l et que vous voyez un identifiant de groupe numérique au lieu d'un nom de groupe, cela signifie que Cygwin ne connaît pas le gid - c'est-à-dire qu'il ne se trouve pas dans /etc/group, et Cygwin ne peut pas l'interroger à partir de Windows. Vous pouvez le confirmer en exécutant getent group <gid>, où <gid> est l'identifiant numérique du groupe.
Pour résoudre ce problème, vous pouvez utiliser chgrp pour modifier le groupe de tous les fichiers/répertoires concernés, comme décrit dans la réponse acceptée ci-dessus, ou créer une entrée pour le gid inconnu dans /etc/group, avec tout nom de groupe inutilisé (par exemple, Users2).
Cela fait, il peut être nécessaire de fermer toutes vos fenêtres Cygwin, puis de les rouvrir.
Une expérience montre que chmod fonctionne correctement pour modifier les autorisations de groupe sous Cygwin.
L'expérience a utilisé un fichier sur une partition NTFS. Cygwin implémente une couche POSIX au-dessus de Windows, mais utilise finalement les fonctionnalités de Windows et de l’implémentation particulière du système de fichiers.
Sur les versions modernes de Windows, la plupart des disques durs sont formatés pour utiliser NTFS, ce qui permet une prise en charge suffisante de chmod. Mais les lecteurs USB externes utilisent généralement FAT32, qui ne dispose pas des mêmes capacités pour représenter les autorisations. La couche Cygwin simule aussi bien que possible la sémantique POSIX, mais elle ne peut en faire que beaucoup.
Essayer
$ df -T .
Si cela indique que vous utilisez un système de fichiers FAT32, c'est probablement le problème. La solution serait de stocker le fichier sur un système de fichiers NTFS à la place. Un fichier nommé id_dsa est probablement une clé privée SSH et doit de toute façon être stocké dans $HOME/.ssh.
Votre répertoire personnel est-il sur une partition FAT32? Si je me souviens bien, les versions récentes de Windows ("récente" signifiant les 10 dernières années ou plus) sont capables de convertir les systèmes de fichiers FAT32 en NTFS.
Le reste de cette réponse était en réponse à la version originale de la question, qui comportait une faute de frappe dans la commande chmod.
Cygwin utilise la version GNU Coreutils de chmod. Ce,
chmod g=0 fileName
n'est pas la syntaxe correcte. Je reçois:
$ chmod g=0 fileName
chmod: invalid mode: `g=0'
Try `chmod --help' for more information.
(Ceci est sous Linux, pas Cygwin, mais ça devrait être pareil.)
Pour désactiver toutes les autorisations de groupe, cela devrait fonctionner:
$ chmod g= fileName
$ ls -l fileName
-rw----r-- 1 kst kst 0 Jun 13 10:31 fileName
Pour voir la documentation chmod:
$ info coreutils chmod
Pour voir la documentation sur le mode de fichier symbolique:
$ info coreutils Symbolic
Le format des modes symboliques est:
[ugoa...][+-=]PERMS...[,...]où PERMS correspond à zéro ou plusieurs lettres de l'ensemble "rwxXst", ou à un seule lettre de l'ensemble 'ugo'.
Comme les réponses précédentes, les groupes non reconnus causent de tels problèmes. Cela arrive surtout dans les domaines Windows.
Le moyen le plus simple de résoudre ce problème consiste à régénérer vos fichiers /etc/passwd et /etc/group (le paramètre -d est requis pour les utilisateurs du domaine):
mkpasswd -l -d > /etc/passwd
mkgroup -l -d > /etc/group
Fermez et relancez Cygwin.
J'ai eu ce problème lorsque je travaillais à distance depuis le domaine et que j'utilisais cygserver.
L'exécution de ls -l a montré un identifiant de groupe numérique au lieu d'un nom de groupe.
J'ai arrêté cygserver, net stop "CYGWIN cygserver et d'autres processus Cygwin, puis j'ai réexécuté le ls -l et les noms de groupe ont ensuite été affichés correctement.
Je suppose que cygserver détenait des informations de groupe de domaine incomplètes.
Après le redémarrage de cygserver, le système a continué à fonctionner correctement.
C'est une question très ennuyante pour moi. Dans mon cas, la solution de user135348 fonctionnait mieux. Le plus gros problème de l'approche chown :Users -R est que chaque fois qu'un nouveau fichier est créé, il est affecté au gid inconnu 1049120. Il est très frustrant de continuer à modifier le gid de fichier.
J'ai aussi essayé mkgroup, mais dans mon cas, cela n'a pas fonctionné: mon gid est 1049120.
Selon les règles expliquées dans Mappage des SID Windows aux valeurs POSID uid/gid:: 0x100000 offset est utilisé pour le compte du domaine principal de la machine . En essayant de supprimer le même offset de 1049120, vous obtenez 544, qui est le RID du groupe d’administrateurs intégré.
Ce compte n'est pas membre du groupe Administrateurs local. nous utilisons SuRun pour accorder des droits d’administrateur sans donner d’authentification. Dans ce cas, mkgroup n'a pas réussi à générer tous les gids possibles.
La modification du fichier de groupe et l'ajout d'un nom de groupe personnalisé semblent toujours résoudre le problème facilement.