Partage (en local) multi-utilisateurs de Partition FAT32 via mount -t vfat ...
3 réponses
Lucien K.
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
Je 'possède' Debian Woody et j'ai un petit problème de montage de partition
Windows.
Juste en intro : Comment sait-on (ou comment root peut savoir) quel
utilisateur à monté un partition donnée, et surtout quel(s) processu(s)
l'utilisent et la rend(ent) indémontable ???
Mon problème : Je souhaite mettre une ligne dans ma /etc/fstab pour monter
une partition FAT32.
Mais je tiens à ce que ce montage possède TOUTES les propriétés suivantes :
- Ma partition FAT32 doit être montée avec le type vfat (exit les types
msdos, ...).
- Tout les dossiers de ma partition doivent pouvoir être listés, modifiés
(entrées), parcourus, renommés/déplacés, créé/supprimé et tout les fichiers
de ma partition doivent pouvoir être lus, écrits, (exécution très
optionnelle), renommés/déplacés, créé/supprimé ; et tout ça par tous les
utilisateurs, sans avoir à la remonter la partition spécialement pour lui.
- Tout Utilisateurs peut monter ou démonter ma partition FAT32, même si elle
a été montée par un autre utilisateur.
- Comment faire (optionnel) si l'on veut desservir un nombre restreint
d'utilisateurs avec ces fonctionnalités ?
Je vous fait part de mes tentatives :
Mettre 'root' et 'lucien' (moi-même lorsque je suis simple utilisateur) dans
le groupe 'users' (ça aurait été plus élégant avec un groupe comme
'fat32fullAccess').
Choisir un umask (option umask de mount) qui ne s'oppose pas aux
permissions ---rwx--- (pleins pouvoirs aux groupes auquel appartient le
monteur (root pour le montage initial) ; le x n'étant peut-être pas
nécessaire si toujours présent pour les dossiers).
Choisir un 'mode' par défaut qui inclut les permissions ---rwx--- (x
peut-être pas nécessaire). => Mais cette option n'existe pas ou n'est pas
prise en compte pour le montage de partitions msdos et dérivées (comme
vfat).
Alors Choisir un 'mode' par défaut de création/ouverture de fichiers ou de
montage (si ça existe) mais temporaire (le temps du montage) pour le monteur
(root pour le montage initial) mais je ne sais pas faire celà, et je ne sais
pas même si celà est possible.
=> Conclusion je n'arrive pas tout seul à faire le montage tant rêvé.
Merci de réfléchir profondément à ce problème.
INDICE (pour trouver la solution) : je suis néophyte ;-)
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
Jay
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
Je 'possède' Debian Woody et j'ai un petit problème de montage de partition Windows.
[...]
- Tout les dossiers de ma partition doivent pouvoir être listés, modifiés (entrées), parcourus, renommés/déplacés, créé/supprimé et tout les fichiers de ma partition doivent pouvoir être lus, écrits, (exécution très optionnelle), renommés/déplacés, créé/supprimé ; et tout ça par tous les utilisateurs, sans avoir à la remonter la partition spécialement pour lui. - Tout Utilisateurs peut monter ou démonter ma partition FAT32, même si elle a été montée par un autre utilisateur.
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
-- "Do not meddle in the affairs of wizards, for you are crunchy and good with ketchup."
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
Je 'possède' Debian Woody et j'ai un petit problème de montage de partition
Windows.
[...]
- Tout les dossiers de ma partition doivent pouvoir être listés, modifiés
(entrées), parcourus, renommés/déplacés, créé/supprimé et tout les fichiers
de ma partition doivent pouvoir être lus, écrits, (exécution très
optionnelle), renommés/déplacés, créé/supprimé ; et tout ça par tous les
utilisateurs, sans avoir à la remonter la partition spécialement pour lui.
- Tout Utilisateurs peut monter ou démonter ma partition FAT32, même si elle
a été montée par un autre utilisateur.
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
--
"Do not meddle in the affairs of wizards, for you are crunchy and good
with ketchup."
Je 'possède' Debian Woody et j'ai un petit problème de montage de partition Windows.
[...]
- Tout les dossiers de ma partition doivent pouvoir être listés, modifiés (entrées), parcourus, renommés/déplacés, créé/supprimé et tout les fichiers de ma partition doivent pouvoir être lus, écrits, (exécution très optionnelle), renommés/déplacés, créé/supprimé ; et tout ça par tous les utilisateurs, sans avoir à la remonter la partition spécialement pour lui. - Tout Utilisateurs peut monter ou démonter ma partition FAT32, même si elle a été montée par un autre utilisateur.
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
-- "Do not meddle in the affairs of wizards, for you are crunchy and good with ketchup."
Lucien K.
"Jay" a écrit dans le message de news:brev7o$1t3f8$
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes options de montage dans mon post, mais j'ai fait tout ça si bien que :
Tout les utilisateurs du goupe 'users' ont bien des droits sur les fichiers et les dossiers de ma partition, DU FAIT de l'option gid correctement positionnée et le l'option umask pas trop restrictive.
Mon problème est en fait que pour une raison inconnue (ou dont je ne connais pas de solution), les permissions INITIALES (avant l'application de l'umask donné en option que j'ai mis à 707 pour permettre les permissions ---rwx--- (---rw---- (umaskq7) suffiraient si l'umask n'affectait pas les répertoires )), que j' 'estime' valoir rwxr-xr-x (755) à défaut de pouvoir les consulter, sont déjà trop restrictives car elles n'autorisent pas les utilisateurs voulus (partageant le groupe 'users' avec le monteur ('root' par exemple au montage initial)) à écrite dans des fichiers ou à modifier les entrées dans les répertoires (ajout/suppression/renommage de fichiers/dossiers).
Dans ma grande ignorance, j'ose supposer que l' 'environnement' du monteur possède une propriété 'mode' qui, conjointement à la propriété 'umask', détermine les attributs de permissions de ses fichiers et dossiers nouvellement créés et, je l'espère, peut-être des partitions qu'il monte aussi.
Ainsi, je crois* qu'une tel propriété 'mode' existe bien et qu'agir dessus affectera les permissions définitives insuflées aux fichiers et dossiers de ma partition à monter.
*En fait, j'ai l'impression que cette propriété 'mode' est plustôt un attribut spécifique à chaque opération de création de fichier (et quelques autres opérations) et que cet attribut 'mode' est souvent supporté par 'mount', mais hélas pas pour les types msdos et companie (dont vfat).
L'environnement connait peut-être alors une propriété de 'mode-par-défaut' qui serait utilisée lorsque l'attribut 'mode' d'une opération n'est pas fourni explicitement, notamment lorsque cet attribut 'mode' n'est pas supporté (exemple : montage du genre : mount -t vfat ...).
Où alors ce sont les propriété de mon point de montage '/mnt/MaPartionWindowsPartagee' (par exemple) qu'il faut que je modifie ?
C'est dans toute cette botte de foin que réside mon problème, pointu comme ... ... une aiguille ;-)
Je m'en vais retourner sous Linux et tripatouiller les permissions de mon point de montage, mais sans grand enthousiasme car ça me paraît illogique rien que d'y penser ...
Y'a des fois comme ça, il ne fait vraiment pas bon être néophyte ...
En espérant avoir été concis et exhaustif, j'attend sagement vos suggestions.
Third time lucky ... :-))
Camaradement, Lucien K.
"Jay" <Jay@free.fr> a écrit dans le message de
news:brev7o$1t3f8$1@ID-80304.news.uni-berlin.de...
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16
équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes
options de montage dans mon post, mais j'ai fait tout ça si bien que :
Tout les utilisateurs du goupe 'users' ont bien des droits sur les fichiers
et les dossiers de ma partition, DU FAIT de l'option gid correctement
positionnée et le l'option umask pas trop restrictive.
Mon problème est en fait que pour une raison inconnue (ou dont je ne connais
pas de solution), les permissions INITIALES (avant l'application de l'umask
donné en option que j'ai mis à 707 pour permettre les permissions ---rwx---
(---rw---- (umaskq7) suffiraient si l'umask n'affectait pas les
répertoires )), que j' 'estime' valoir rwxr-xr-x (755) à défaut de pouvoir
les consulter, sont déjà trop restrictives car elles n'autorisent pas les
utilisateurs voulus (partageant le groupe 'users' avec le monteur ('root'
par exemple au montage initial)) à écrite dans des fichiers ou à modifier
les entrées dans les répertoires (ajout/suppression/renommage de
fichiers/dossiers).
Dans ma grande ignorance, j'ose supposer que l' 'environnement' du monteur
possède une propriété 'mode' qui, conjointement à la propriété 'umask',
détermine les attributs de permissions de ses fichiers et dossiers
nouvellement créés et, je l'espère, peut-être des partitions qu'il monte
aussi.
Ainsi, je crois* qu'une tel propriété 'mode' existe bien et qu'agir dessus
affectera les permissions définitives insuflées aux fichiers et dossiers de
ma partition à monter.
*En fait, j'ai l'impression que cette propriété 'mode' est plustôt un
attribut spécifique à chaque opération de création de fichier (et quelques
autres opérations) et que cet attribut 'mode' est souvent supporté par
'mount', mais hélas pas pour les types msdos et companie (dont vfat).
L'environnement connait peut-être alors une propriété de 'mode-par-défaut'
qui serait utilisée lorsque l'attribut 'mode' d'une opération n'est pas
fourni explicitement, notamment lorsque cet attribut 'mode' n'est pas
supporté (exemple : montage du genre : mount -t vfat ...).
Où alors ce sont les propriété de mon point de montage
'/mnt/MaPartionWindowsPartagee' (par exemple) qu'il faut que je modifie ?
C'est dans toute cette botte de foin que réside mon problème, pointu comme
...
... une aiguille ;-)
Je m'en vais retourner sous Linux et tripatouiller les permissions de mon
point de montage, mais sans grand enthousiasme car ça me paraît illogique
rien que d'y penser ...
Y'a des fois comme ça, il ne fait vraiment pas bon être néophyte ...
En espérant avoir été concis et exhaustif, j'attend sagement vos
suggestions.
"Jay" a écrit dans le message de news:brev7o$1t3f8$
<< Répondre sur ce NG -- MERCI >>
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes options de montage dans mon post, mais j'ai fait tout ça si bien que :
Tout les utilisateurs du goupe 'users' ont bien des droits sur les fichiers et les dossiers de ma partition, DU FAIT de l'option gid correctement positionnée et le l'option umask pas trop restrictive.
Mon problème est en fait que pour une raison inconnue (ou dont je ne connais pas de solution), les permissions INITIALES (avant l'application de l'umask donné en option que j'ai mis à 707 pour permettre les permissions ---rwx--- (---rw---- (umaskq7) suffiraient si l'umask n'affectait pas les répertoires )), que j' 'estime' valoir rwxr-xr-x (755) à défaut de pouvoir les consulter, sont déjà trop restrictives car elles n'autorisent pas les utilisateurs voulus (partageant le groupe 'users' avec le monteur ('root' par exemple au montage initial)) à écrite dans des fichiers ou à modifier les entrées dans les répertoires (ajout/suppression/renommage de fichiers/dossiers).
Dans ma grande ignorance, j'ose supposer que l' 'environnement' du monteur possède une propriété 'mode' qui, conjointement à la propriété 'umask', détermine les attributs de permissions de ses fichiers et dossiers nouvellement créés et, je l'espère, peut-être des partitions qu'il monte aussi.
Ainsi, je crois* qu'une tel propriété 'mode' existe bien et qu'agir dessus affectera les permissions définitives insuflées aux fichiers et dossiers de ma partition à monter.
*En fait, j'ai l'impression que cette propriété 'mode' est plustôt un attribut spécifique à chaque opération de création de fichier (et quelques autres opérations) et que cet attribut 'mode' est souvent supporté par 'mount', mais hélas pas pour les types msdos et companie (dont vfat).
L'environnement connait peut-être alors une propriété de 'mode-par-défaut' qui serait utilisée lorsque l'attribut 'mode' d'une opération n'est pas fourni explicitement, notamment lorsque cet attribut 'mode' n'est pas supporté (exemple : montage du genre : mount -t vfat ...).
Où alors ce sont les propriété de mon point de montage '/mnt/MaPartionWindowsPartagee' (par exemple) qu'il faut que je modifie ?
C'est dans toute cette botte de foin que réside mon problème, pointu comme ... ... une aiguille ;-)
Je m'en vais retourner sous Linux et tripatouiller les permissions de mon point de montage, mais sans grand enthousiasme car ça me paraît illogique rien que d'y penser ...
Y'a des fois comme ça, il ne fait vraiment pas bon être néophyte ...
En espérant avoir été concis et exhaustif, j'attend sagement vos suggestions.
Third time lucky ... :-))
Camaradement, Lucien K.
Lucien K.
"Lucien K." a écrit dans le message de news:brf2q7$a76$
"Jay" a écrit dans le message de
"Lucien K." :
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes options de montage dans mon post, mais j'ai fait tout ça si bien que : [...]
~ > Ca marche mais moyennement ~ (Lucien K.)
<< Répondre sur ce NG -- MERCI >>
Bonjour,
Fort du non-soutient de la communauté, j'ai néanmoins progressé et je souhaiterai en faire bénéficier tout le monde.
Je dois certes avouer que j'attend des pistes, ou même de simples commentaires, quand aux possibilités de faire évoluer un peu mon montage de partition FAT32, voir même la prise en charge des systèmes de fichiers FAT et dérivés sous Linux (ou autres Unix-Like) !!!
Voici mon problème :
- Résumé (récapitulatif) concis et suffisant de la situation : Au démarrage du système (je tourne sous Debian 3 (Woody)), la fstab monte une partition FAT32 avec les options suivantes : -> type : vfat -> options : rw,suid=0,guid 00,umaskp7,users,noexec,uni_xlate,nodev où guid 00 indique le guid du groupe 'FatUsers' auquel root et d'autres utilisateurs appartiennent.
- Enoncé de la problématique : Ce montage à été créé dans l'intention que tout utilisateur [membre] du groupe 'FatUsers' puisse effectuer toutes les opérations [imaginables] sur les dossiers et les fichiers de cette partition FAT32 et ce même sans qu'il soit [nécessairement] l'utilisateur ayant monté cette partition, et que tous ces utilisateurs puissent exploiter cette partition simultanément (sans avoir à demander au 'monteur' de la démonter pour qu'il puisse la remonter lui-même). Cette description de l'intention suivie rend bien compte du fait que l'implémentation (la réalisation dans la fstab, ou tout montage manuel utilisant les mêmes options) ne repose que sur les permissions induites par : -> l'umask (passé en option) -> l'appartenance (de chaque utilisateur concerné) au groupe 'FatUsers'.
Mais dans la pratique il y a quelques problèmes : -> Les fichiers ayant l'attribut (au sens MS-DOS du terme) ReadOnly (voir peut-être certaines [autres] combinaisons des 4 attributs possibles) sont 'retranscrits' avec la permission 'moins Write pour le groupe' (reste ---r-----) -> A cause de l'umask 022 par défaut pour l'environnement de tout utilisateur, tout fichier créé sur la partition [par un utilisateur], lors de tâches de bureautique ordinaire par exemple, est crée avec les permissions ---r----- lesquelles (permissions) ne peuvent généralement plus être ramenées à ---rw---- par cet utilisateur car il n'est (généralement) pas l'utilisateur ayant monté la partition FAT32 (en effet, tout fichier/dossier sur une cette partition est réputé appartenir à l'utilisateur qui l'a monté, le seul (avec root) à pouvoir changer les propriétés du fichier/dossier). -> Définir un umask 002 pour tout utilisateur devant utiliser cette partition me semble être une faille de sécurité énorme ... car plusieurs utilisateurs pourraient vouloir expoorter des informations (en lecture seule) en s'enregistrant dans un groupe spécifique ('DocumentsALire' par exemple) alors que leurs documents seraient créés par défaut avec les permissions ---rw---- !!! Sur ce NG, des utilisateurs non-novices (au contraire de moi) auraient sans doute beaucoup à dire quant aux failles induites par un tel umask valant 002 pour quasiment tout un chacun !
==>> Du coup, je ne vois pas comment réaliser un montage de partition FAT ou dérivée qui reflète l'intention que j'ai décrit plus haut (sans désécuriser le système dans ses autres utilisations).
Quelqu'un aurait-il suffisament de dextérité pour me sortir de cette impasse ? Je l'expère pour le communauté bicorne. Another day ...
Allez, un petit effort : je suis sûr que, à défaut de résoudre mon problème, vous mettrez en exergue les insuffisances dans le support des partitions FAT, y trouverez peut-être des solutions et en ferez bénéficier des personnes qui en ont sans-doute autrement davantage besoin que moi ;-)
Rappel et résumé : Le noyau de l'affaire est que tout fichier créé dans une telle partition FAT appartient désormais ... à l'utilisateur qui à monté cette même partition, ce qui empêche l' 'auteur' de le mettre en partage ---rw---- !
En tout cas, merci de vous pencher sur ce sujet que me semble ardu.
<< Répondre sur ce NG -- MERCI >>
Camaradement, Lucien K.
"Lucien K." <LucienK_Orphan@NoMail.Com> a écrit dans le message de
news:brf2q7$a76$1@news-reader5.wanadoo.fr...
"Jay" <Jay@free.fr> a écrit dans le message de
"Lucien K." :
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16
équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes
options de montage dans mon post, mais j'ai fait tout ça si bien que :
[...]
~ > Ca marche mais moyennement ~ (Lucien K.)
<< Répondre sur ce NG -- MERCI >>
Bonjour,
Fort du non-soutient de la communauté, j'ai néanmoins progressé et je
souhaiterai en faire bénéficier tout le monde.
Je dois certes avouer que j'attend des pistes, ou même de simples
commentaires, quand aux possibilités de faire évoluer un peu mon montage de
partition FAT32, voir même la prise en charge des systèmes de fichiers FAT
et dérivés sous Linux (ou autres Unix-Like) !!!
Voici mon problème :
- Résumé (récapitulatif) concis et suffisant de la situation :
Au démarrage du système (je tourne sous Debian 3 (Woody)), la fstab
monte une partition FAT32 avec les options suivantes :
-> type : vfat
-> options : rw,suid=0,guid 00,umaskp7,users,noexec,uni_xlate,nodev
où guid 00 indique le guid du groupe 'FatUsers' auquel root et d'autres
utilisateurs appartiennent.
- Enoncé de la problématique :
Ce montage à été créé dans l'intention que tout utilisateur [membre] du
groupe 'FatUsers' puisse effectuer toutes les opérations [imaginables] sur
les dossiers et les fichiers de cette partition FAT32 et ce même sans qu'il
soit [nécessairement] l'utilisateur ayant monté cette partition, et que tous
ces utilisateurs puissent exploiter cette partition simultanément (sans
avoir à demander au 'monteur' de la démonter pour qu'il puisse la remonter
lui-même).
Cette description de l'intention suivie rend bien compte du fait que
l'implémentation (la réalisation dans la fstab, ou tout montage manuel
utilisant les mêmes options) ne repose que sur les permissions induites par
:
-> l'umask (passé en option)
-> l'appartenance (de chaque utilisateur concerné) au groupe 'FatUsers'.
Mais dans la pratique il y a quelques problèmes :
-> Les fichiers ayant l'attribut (au sens MS-DOS du terme) ReadOnly (voir
peut-être certaines [autres] combinaisons des 4 attributs possibles) sont
'retranscrits' avec la permission 'moins Write pour le groupe'
(reste ---r-----)
-> A cause de l'umask 022 par défaut pour l'environnement de tout
utilisateur, tout fichier créé sur la partition [par un utilisateur], lors
de tâches de bureautique ordinaire par exemple, est crée avec les
permissions ---r----- lesquelles (permissions) ne peuvent généralement plus
être ramenées à ---rw---- par cet utilisateur car il n'est (généralement)
pas l'utilisateur ayant monté la partition FAT32 (en effet, tout
fichier/dossier sur une cette partition est réputé appartenir à
l'utilisateur qui l'a monté, le seul (avec root) à pouvoir changer les
propriétés du fichier/dossier).
-> Définir un umask 002 pour tout utilisateur devant utiliser cette
partition me semble être une faille de sécurité énorme ... car plusieurs
utilisateurs pourraient vouloir expoorter des informations (en lecture
seule) en s'enregistrant dans un groupe spécifique ('DocumentsALire' par
exemple) alors que leurs documents seraient créés par défaut avec les
permissions ---rw---- !!! Sur ce NG, des utilisateurs non-novices (au
contraire de moi) auraient sans doute beaucoup à dire quant aux failles
induites par un tel umask valant 002 pour quasiment tout un chacun !
==>> Du coup, je ne vois pas comment réaliser un montage de partition FAT ou
dérivée qui reflète l'intention que j'ai décrit plus haut (sans désécuriser
le système dans ses autres utilisations).
Quelqu'un aurait-il suffisament de dextérité pour me sortir de cette impasse
?
Je l'expère pour le communauté bicorne. Another day ...
Allez, un petit effort : je suis sûr que, à défaut de résoudre mon problème,
vous mettrez en exergue les insuffisances dans le support des partitions
FAT, y trouverez peut-être des solutions et en ferez bénéficier des
personnes qui en ont sans-doute autrement davantage besoin que moi ;-)
Rappel et résumé : Le noyau de l'affaire est que tout fichier créé dans une
telle partition FAT appartient désormais ... à l'utilisateur qui à monté
cette même partition, ce qui empêche l' 'auteur' de le mettre en
partage ---rw---- !
En tout cas, merci de vous pencher sur ce sujet que me semble ardu.
"Lucien K." a écrit dans le message de news:brf2q7$a76$
"Jay" a écrit dans le message de
"Lucien K." :
Bonjour, toutes et tous.
[...]
As-tu essayé un truc du genre :
/dev/hda1 /mnt/win vfat rw,user,gid 0 0
gid correspondant à un groupe donné ? Par exemple, avec disons 16 équivalent
au groupe "disk" ou "fat" ou ce que tu veux d'autre ?
Oupsss : Je suis vraiment CON au sens où j'ai oublié de bien préciser mes options de montage dans mon post, mais j'ai fait tout ça si bien que : [...]
~ > Ca marche mais moyennement ~ (Lucien K.)
<< Répondre sur ce NG -- MERCI >>
Bonjour,
Fort du non-soutient de la communauté, j'ai néanmoins progressé et je souhaiterai en faire bénéficier tout le monde.
Je dois certes avouer que j'attend des pistes, ou même de simples commentaires, quand aux possibilités de faire évoluer un peu mon montage de partition FAT32, voir même la prise en charge des systèmes de fichiers FAT et dérivés sous Linux (ou autres Unix-Like) !!!
Voici mon problème :
- Résumé (récapitulatif) concis et suffisant de la situation : Au démarrage du système (je tourne sous Debian 3 (Woody)), la fstab monte une partition FAT32 avec les options suivantes : -> type : vfat -> options : rw,suid=0,guid 00,umaskp7,users,noexec,uni_xlate,nodev où guid 00 indique le guid du groupe 'FatUsers' auquel root et d'autres utilisateurs appartiennent.
- Enoncé de la problématique : Ce montage à été créé dans l'intention que tout utilisateur [membre] du groupe 'FatUsers' puisse effectuer toutes les opérations [imaginables] sur les dossiers et les fichiers de cette partition FAT32 et ce même sans qu'il soit [nécessairement] l'utilisateur ayant monté cette partition, et que tous ces utilisateurs puissent exploiter cette partition simultanément (sans avoir à demander au 'monteur' de la démonter pour qu'il puisse la remonter lui-même). Cette description de l'intention suivie rend bien compte du fait que l'implémentation (la réalisation dans la fstab, ou tout montage manuel utilisant les mêmes options) ne repose que sur les permissions induites par : -> l'umask (passé en option) -> l'appartenance (de chaque utilisateur concerné) au groupe 'FatUsers'.
Mais dans la pratique il y a quelques problèmes : -> Les fichiers ayant l'attribut (au sens MS-DOS du terme) ReadOnly (voir peut-être certaines [autres] combinaisons des 4 attributs possibles) sont 'retranscrits' avec la permission 'moins Write pour le groupe' (reste ---r-----) -> A cause de l'umask 022 par défaut pour l'environnement de tout utilisateur, tout fichier créé sur la partition [par un utilisateur], lors de tâches de bureautique ordinaire par exemple, est crée avec les permissions ---r----- lesquelles (permissions) ne peuvent généralement plus être ramenées à ---rw---- par cet utilisateur car il n'est (généralement) pas l'utilisateur ayant monté la partition FAT32 (en effet, tout fichier/dossier sur une cette partition est réputé appartenir à l'utilisateur qui l'a monté, le seul (avec root) à pouvoir changer les propriétés du fichier/dossier). -> Définir un umask 002 pour tout utilisateur devant utiliser cette partition me semble être une faille de sécurité énorme ... car plusieurs utilisateurs pourraient vouloir expoorter des informations (en lecture seule) en s'enregistrant dans un groupe spécifique ('DocumentsALire' par exemple) alors que leurs documents seraient créés par défaut avec les permissions ---rw---- !!! Sur ce NG, des utilisateurs non-novices (au contraire de moi) auraient sans doute beaucoup à dire quant aux failles induites par un tel umask valant 002 pour quasiment tout un chacun !
==>> Du coup, je ne vois pas comment réaliser un montage de partition FAT ou dérivée qui reflète l'intention que j'ai décrit plus haut (sans désécuriser le système dans ses autres utilisations).
Quelqu'un aurait-il suffisament de dextérité pour me sortir de cette impasse ? Je l'expère pour le communauté bicorne. Another day ...
Allez, un petit effort : je suis sûr que, à défaut de résoudre mon problème, vous mettrez en exergue les insuffisances dans le support des partitions FAT, y trouverez peut-être des solutions et en ferez bénéficier des personnes qui en ont sans-doute autrement davantage besoin que moi ;-)
Rappel et résumé : Le noyau de l'affaire est que tout fichier créé dans une telle partition FAT appartient désormais ... à l'utilisateur qui à monté cette même partition, ce qui empêche l' 'auteur' de le mettre en partage ---rw---- !
En tout cas, merci de vous pencher sur ce sujet que me semble ardu.
