J'ai installé il y a peu vdr(1), version 1.7.28, et c'est très pratique.
Cependant, par défaut les nouveaux fichiers et dossiers sont créés avec
les droits RW pour le propriétaire vdr, et R seulement pour le groupe et
autres utilisateurs.
J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler
les fichiers créés sans devoir passer par un sudo. Mais je n'ai pas
trouvé dans le fichier config ou sur le net (pas su chercher ?).
Est-ce que quelqu'un a une petite idée ?
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
yamo'
franssoa a tapoté, le 27/03/2013 10:01:
Bonjour,
J'ai installé il y a peu vdr(1), version 1.7.28, et c'est très pratique. Cependant, par défaut les nouveaux fichiers et dossiers sont créés avec les droits RW pour le propriétaire vdr, et R seulement pour le groupe et autres utilisateurs. J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler les fichiers créés sans devoir passer par un sudo. Mais je n'ai pas trouvé dans le fichier config ou sur le net (pas su chercher ?). Est-ce que quelqu'un a une petite idée ?
Modifier l'umask de l'utilisateur vdr en le passant à 002.
need to wrap system in aluminum foil to fix problem
franssoa a tapoté, le 27/03/2013 10:01:
Bonjour,
J'ai installé il y a peu vdr(1), version 1.7.28, et c'est très pratique.
Cependant, par défaut les nouveaux fichiers et dossiers sont créés avec
les droits RW pour le propriétaire vdr, et R seulement pour le groupe et
autres utilisateurs.
J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler
les fichiers créés sans devoir passer par un sudo. Mais je n'ai pas
trouvé dans le fichier config ou sur le net (pas su chercher ?).
Est-ce que quelqu'un a une petite idée ?
Modifier l'umask de l'utilisateur vdr en le passant à 002.
J'ai installé il y a peu vdr(1), version 1.7.28, et c'est très pratique. Cependant, par défaut les nouveaux fichiers et dossiers sont créés avec les droits RW pour le propriétaire vdr, et R seulement pour le groupe et autres utilisateurs. J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler les fichiers créés sans devoir passer par un sudo. Mais je n'ai pas trouvé dans le fichier config ou sur le net (pas su chercher ?). Est-ce que quelqu'un a une petite idée ?
Modifier l'umask de l'utilisateur vdr en le passant à 002.
need to wrap system in aluminum foil to fix problem
franssoa
Le 27. 03. 13 10:53, yamo' a écrit :
franssoa a tapoté, le 27/03/2013 10:01:
J'ai installé vdr(...) J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler les fichiers créés sans devoir passer par un sudo.
Modifier l'umask de l'utilisateur vdr en le passant à 002.
Je n'ai jamais manipulé umask avant. J'ai potassé un peu sur le net et effectivement cela parait-être la solution.
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask soit pour tout le système, soit pour un utilisateur ordinaire, se loggant dans son dossier home. Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login.
Bref, je ne sais pas modifier l'umask de vdr :-(
franssoa
PS:ubuntu 12.10
Le 27. 03. 13 10:53, yamo' a écrit :
franssoa a tapoté, le 27/03/2013 10:01:
J'ai installé vdr(...) J'aimerais avoir aussi les droits W pour le
groupe, afin de manipuler les fichiers créés sans devoir passer par
un sudo.
Modifier l'umask de l'utilisateur vdr en le passant à 002.
Je n'ai jamais manipulé umask avant. J'ai potassé un peu sur le net et
effectivement cela parait-être la solution.
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask
soit pour tout le système, soit pour un utilisateur ordinaire, se
loggant dans son dossier home.
Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le
programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login.
J'ai installé vdr(...) J'aimerais avoir aussi les droits W pour le groupe, afin de manipuler les fichiers créés sans devoir passer par un sudo.
Modifier l'umask de l'utilisateur vdr en le passant à 002.
Je n'ai jamais manipulé umask avant. J'ai potassé un peu sur le net et effectivement cela parait-être la solution.
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask soit pour tout le système, soit pour un utilisateur ordinaire, se loggant dans son dossier home. Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login.
Bref, je ne sais pas modifier l'umask de vdr :-(
franssoa
PS:ubuntu 12.10
franssoa
Le 27. 03. 13 11:36, franssoa a écrit :
Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login. Bref, je ne sais pas modifier l'umask de vdr :-(
Une piste là (1) ?
Peut-on rajouter à la main dans /etc/password un home pour un utilisateur système ?
Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le
programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login.
Bref, je ne sais pas modifier l'umask de vdr :-(
Une piste là (1) ?
Peut-on rajouter à la main dans /etc/password un home pour un
utilisateur système ?
Dans mon cas, vdr (l'utilisateur propriétaire des fichiers créés par le programme vdr) à un UID de 107 (116 pour le groupe vdr) et pas de login. Bref, je ne sais pas modifier l'umask de vdr :-(
Une piste là (1) ?
Peut-on rajouter à la main dans /etc/password un home pour un utilisateur système ?
franssoa , dans le message <kiuhvs$on9$, a écrit :
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask soit pour tout le système, soit pour un utilisateur ordinaire, se loggant dans son dossier home.
L'umask est une propriété des processus, chaque processus en a un séparément. Par défaut, un processus reçoit l'umask de son processus père, mais il peut le changer, et ces changements seront transmis aux processus fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
franssoa , dans le message <kiuhvs$on9$1@dont-email.me>, a écrit :
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask
soit pour tout le système, soit pour un utilisateur ordinaire, se
loggant dans son dossier home.
L'umask est une propriété des processus, chaque processus en a un
séparément. Par défaut, un processus reçoit l'umask de son processus père,
mais il peut le changer, et ces changements seront transmis aux processus
fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement parce
qu'un des programmes qui interviennent dans l'ouverture de la session lit ce
fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande
idoine dans les scripts qui servent à le lancer.
franssoa , dans le message <kiuhvs$on9$, a écrit :
Hélas, tout ce que j'y ai vu jusqu'à présent permet de fixer l'umask soit pour tout le système, soit pour un utilisateur ordinaire, se loggant dans son dossier home.
L'umask est une propriété des processus, chaque processus en a un séparément. Par défaut, un processus reçoit l'umask de son processus père, mais il peut le changer, et ces changements seront transmis aux processus fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
Nicolas George
franssoa , dans le message <kiuipu$ssh$, a écrit :
Peut-on rajouter à la main dans /etc/password un home pour un utilisateur système ?
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
Parfait ! J'ai vu que la fonction start-stop-daemon a justement un attribut --umask qui est fait pour ça. J'ai donc modifié le script de lancement en y ajoutant --umask 002 et ça fonctionne.
Merci à tous. franssoa
Le 27. 03. 13 12:13, Nicolas George a écrit :
L'umask des utilisateurs est réglé par un fichier de config simplement parce
qu'un des programmes qui interviennent dans l'ouverture de la session lit ce
fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande
idoine dans les scripts qui servent à le lancer.
Parfait !
J'ai vu que la fonction start-stop-daemon a justement un attribut
--umask qui est fait pour ça. J'ai donc modifié le script de lancement
en y ajoutant --umask 002 et ça fonctionne.
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
Parfait ! J'ai vu que la fonction start-stop-daemon a justement un attribut --umask qui est fait pour ça. J'ai donc modifié le script de lancement en y ajoutant --umask 002 et ça fonctionne.
Merci à tous. franssoa
Sergio
Le Wed, 27 Mar 2013 11:13:41 +0000, Nicolas George a écrit :
L'umask est une propriété des processus, chaque processus en a un séparément. Par défaut, un processus reçoit l'umask de son processus père, mais il peut le changer, et ces changements seront transmis aux processus fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
Ça m'intéresse... Mais ce script est remis à zéro à chaque mise-à-jour, réinstallation ?
Le Wed, 27 Mar 2013 11:13:41 +0000, Nicolas George a écrit :
L'umask est une propriété des processus, chaque processus en a un
séparément. Par défaut, un processus reçoit l'umask de son processus
père,
mais il peut le changer, et ces changements seront transmis aux
processus fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement
parce qu'un des programmes qui interviennent dans l'ouverture de la
session lit ce fichier de config et met à jour son umask. C'est
fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande
idoine dans les scripts qui servent à le lancer.
Ça m'intéresse... Mais ce script est remis à zéro à chaque mise-à-jour,
réinstallation ?
Le Wed, 27 Mar 2013 11:13:41 +0000, Nicolas George a écrit :
L'umask est une propriété des processus, chaque processus en a un séparément. Par défaut, un processus reçoit l'umask de son processus père, mais il peut le changer, et ces changements seront transmis aux processus fils qui seront créés ultérieurement.
L'umask des utilisateurs est réglé par un fichier de config simplement parce qu'un des programmes qui interviennent dans l'ouverture de la session lit ce fichier de config et met à jour son umask. C'est fréquemment un shell.
Pour faire la même chose pour un démon, il suffit d'ajouter la commande idoine dans les scripts qui servent à le lancer.
Ça m'intéresse... Mais ce script est remis à zéro à chaque mise-à-jour, réinstallation ?
