Ton raisonnement est beau mais... Comment le système reconnaît l'utilisateur qui a branché le périphérique ? (s'il y a plusieurs utilisateurs connectés à cet instant, bien sûr...).
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
Ton raisonnement est beau mais...
Comment le système reconnaît l'utilisateur qui a branché le
périphérique ? (s'il y a plusieurs utilisateurs connectés à cet instant,
bien sûr...).
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
Ton raisonnement est beau mais... Comment le système reconnaît l'utilisateur qui a branché le périphérique ? (s'il y a plusieurs utilisateurs connectés à cet instant, bien sûr...).
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Le 19/06/2013 20:36, Baton .rouge a écrit :
On Wed, 19 Jun 2013 17:21:00 +0200, Pascal <xxx.xxx@xxx.fr> wrote:
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis
peu, il semble que pour des raisons de sécurité ce soit maintenant
/media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un
montage automatique ? Se sera root à chaque fois ?
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Philippe
Le Wed, 19 Jun 2013 21:31:56 +0200, jp willm a écrit :
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
Toutes ces facilités là ne sont pas faites pour les serveurs, même si elles existent là aussi. Dans mon cas, l'usage principal de Linux, c'est de sensibiliser mes rejetons aux problèmes de sécurité en premier chef puis de leur apprendre a s'intéresser à l'alternative quand elle existe. Cette préoccupation du montage d'accessoires prends alors une place plus importante qu'elle ne devrait.
Je regrette toujours la mort d'OS/2...
-- la moralisation avance a pas de Guéant Philippe Vessaire Ò¿Ó¬
Le Wed, 19 Jun 2013 21:31:56 +0200, jp willm a écrit :
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
Toutes ces facilités là ne sont pas faites pour les serveurs, même si
elles existent là aussi.
Dans mon cas, l'usage principal de Linux, c'est de sensibiliser mes
rejetons aux problèmes de sécurité en premier chef puis de leur apprendre
a s'intéresser à l'alternative quand elle existe. Cette préoccupation du
montage d'accessoires prends alors une place plus importante qu'elle ne
devrait.
Je regrette toujours la mort d'OS/2...
--
la moralisation avance a pas de Guéant
Philippe Vessaire Ò¿Ó¬
Le Wed, 19 Jun 2013 21:31:56 +0200, jp willm a écrit :
Bah, je pensais à un serveur et plusieurs terminaux utilisateurs.
Mais bon, j'ai peut-être plus d'imagination que de science :o)
Toutes ces facilités là ne sont pas faites pour les serveurs, même si elles existent là aussi. Dans mon cas, l'usage principal de Linux, c'est de sensibiliser mes rejetons aux problèmes de sécurité en premier chef puis de leur apprendre a s'intéresser à l'alternative quand elle existe. Cette préoccupation du montage d'accessoires prends alors une place plus importante qu'elle ne devrait.
Je regrette toujours la mort d'OS/2...
-- la moralisation avance a pas de Guéant Philippe Vessaire Ò¿Ó¬
Baton .rouge
On Wed, 19 Jun 2013 21:46:40 +0200, Pascal wrote:
Le 19/06/2013 20:36, Baton .rouge a écrit :
On Wed, 19 Jun 2013 17:21:00 +0200, Pascal wrote:
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ? -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Wed, 19 Jun 2013 21:46:40 +0200, Pascal <xxx.xxx@xxx.fr> wrote:
Le 19/06/2013 20:36, Baton .rouge a écrit :
On Wed, 19 Jun 2013 17:21:00 +0200, Pascal <xxx.xxx@xxx.fr> wrote:
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis
peu, il semble que pour des raisons de sécurité ce soit maintenant
/media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un
montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique
?
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ? -- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
YBM
Le 19.06.2013 22:14, Baton .rouge a écrit :
On Wed, 19 Jun 2013 21:46:40 +0200, Pascal wrote:
Le 19/06/2013 20:36, Baton .rouge a écrit :
On Wed, 19 Jun 2013 17:21:00 +0200, Pascal wrote:
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Celui qui est connecté localement, ce qui pose un problème, pour les stations de travail, en multihead.
Le 19.06.2013 22:14, Baton .rouge a écrit :
On Wed, 19 Jun 2013 21:46:40 +0200, Pascal <xxx.xxx@xxx.fr> wrote:
Le 19/06/2013 20:36, Baton .rouge a écrit :
On Wed, 19 Jun 2013 17:21:00 +0200, Pascal <xxx.xxx@xxx.fr> wrote:
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis
peu, il semble que pour des raisons de sécurité ce soit maintenant
/media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un
montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique
?
Celui qui est connecté localement, ce qui pose un problème, pour les
stations de travail, en multihead.
En fait l'ancien fonctionnement était /media/nom_du_périph, mais depuis peu, il semble que pour des raisons de sécurité ce soit maintenant /media/user/nom_du_périph.
ça c'est valable pour le user qui mount manuelement. Mais quid d'un montage automatique ? Se sera root à chaque fois ?
Je parlais bien d'un montage automatique là
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Celui qui est connecté localement, ce qui pose un problème, pour les stations de travail, en multihead.
moi-meme
Le Wed, 19 Jun 2013 22:14:20 +0200, Baton .rouge a écrit :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Avec rox, on monte lors de l'accès au point de montage si le périphérique est déclaré dans fstab. et si le montage par l'utilisateur est autorisé
L'utilisateur est connu et les droits sont ceux donnés par fstab.
orsqu'on quitte le pointe de montage : on démonte et on synchronise (logique non).
Pas d'action cachée.
Le Wed, 19 Jun 2013 22:14:20 +0200, Baton .rouge a écrit :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Avec rox, on monte lors de l'accès au point de montage si le périphérique
est déclaré dans fstab. et si le montage par l'utilisateur est autorisé
L'utilisateur est connu et les droits sont ceux donnés par fstab.
orsqu'on quitte le pointe de montage : on démonte et on synchronise
(logique non).
Le Wed, 19 Jun 2013 22:14:20 +0200, Baton .rouge a écrit :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Avec rox, on monte lors de l'accès au point de montage si le périphérique est déclaré dans fstab. et si le montage par l'utilisateur est autorisé
L'utilisateur est connu et les droits sont ceux donnés par fstab.
orsqu'on quitte le pointe de montage : on démonte et on synchronise (logique non).
Pas d'action cachée.
Cyprien Nicolas
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des hooks sur les évènements udev, on ne peut pas déterminer forcément qui est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev" générique pour accéder à ces périphériques.
-- « Ceci n'est pas une signature. » — René Magritte (Apocryphe)
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en
automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de
maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux,
il n'y a qu'une seule session graphique active en mème temps. Les
gestionnaires de sessions écoutent les évènements DBus de connexion des
périphériques amovibles, et le montent automatiquement pour
l'utilisateur connecté (GDM, KDM notamment, avec les environnements de
bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des
hooks sur les évènements udev, on ne peut pas déterminer forcément qui
est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev"
générique pour accéder à ces périphériques.
--
« Ceci n'est pas une signature. » — René Magritte (Apocryphe)
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des hooks sur les évènements udev, on ne peut pas déterminer forcément qui est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev" générique pour accéder à ces périphériques.
-- « Ceci n'est pas une signature. » — René Magritte (Apocryphe)
Baton .rouge
On Thu, 20 Jun 2013 11:59:06 +0200, Cyprien Nicolas wrote:
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des hooks sur les évènements udev, on ne peut pas déterminer forcément qui est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev" générique pour accéder à ces périphériques.
Ok, merci pour ces infos.
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Thu, 20 Jun 2013 11:59:06 +0200, Cyprien Nicolas
<cyp-nospam@fulax.fr> wrote:
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en
automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de
maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux,
il n'y a qu'une seule session graphique active en mème temps. Les
gestionnaires de sessions écoutent les évènements DBus de connexion des
périphériques amovibles, et le montent automatiquement pour
l'utilisateur connecté (GDM, KDM notamment, avec les environnements de
bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des
hooks sur les évènements udev, on ne peut pas déterminer forcément qui
est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev"
générique pour accéder à ces périphériques.
Ok, merci pour ces infos.
--
Vous voulez un conseil ?
Ne faites jamais confiance à ceux qui vous donnent des conseils.
On Thu, 20 Jun 2013 11:59:06 +0200, Cyprien Nicolas wrote:
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Sur des systèmes ou l'automontage est moins intégré, par exemple via des hooks sur les évènements udev, on ne peut pas déterminer forcément qui est "assis" devant le PC, d'où l'utilisation d'un groupe "plugdev" générique pour accéder à ces périphériques.
Ok, merci pour ces infos.
-- Vous voulez un conseil ? Ne faites jamais confiance à ceux qui vous donnent des conseils.
Erwan David
Cyprien Nicolas écrivait :
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Ce n'est que parceque ces environnements sont trop limités pour tirer partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
-- Les simplifications c'est trop compliqué
Cyprien Nicolas <cyp-nospam@fulax.fr> écrivait :
Le 19/06/2013 à 22:14, Baton .rouge écrivît :
Comment l'OS sait qui est l'USER qui a branché la clé en
automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de
maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux,
il n'y a qu'une seule session graphique active en mème temps. Les
gestionnaires de sessions écoutent les évènements DBus de connexion des
périphériques amovibles, et le montent automatiquement pour
l'utilisateur connecté (GDM, KDM notamment, avec les environnements de
bureau associés).
Ce n'est que parceque ces environnements sont trop limités pour tirer
partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
Comment l'OS sait qui est l'USER qui a branché la clé en automatique ?
Selon la distribution, il y a en général ConsoleKit en charge de maintenir qui est loggué. Les sessions sont listables via la commande :
$ ck-list-sessions
ou alors, avec systemd/logind, les commandes list-bidule :
$ systemd-loginctl list-{seats,sessions,users}
Dans la plupart des cas, en Desktop avec les environnements principaux, il n'y a qu'une seule session graphique active en mème temps. Les gestionnaires de sessions écoutent les évènements DBus de connexion des périphériques amovibles, et le montent automatiquement pour l'utilisateur connecté (GDM, KDM notamment, avec les environnements de bureau associés).
Ce n'est que parceque ces environnements sont trop limités pour tirer partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
-- Les simplifications c'est trop compliqué
Cyprien Nicolas
Le 20/06/2013 à 18:23, Erwan David écrivît :
Ce n'est que parceque ces environnements sont trop limités pour tirer partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
Il y a 20 ans, on avait pas de clefs USB, pas de DBus, pas de *kit ni de systemd. Et il me semble qu'on ne pouvait pas sauver ses fichiers sur disquettes depuis un terminal X :-).
-- « Ceci n'est pas une signature. » — René Magritte (Apocryphe)
Le 20/06/2013 à 18:23, Erwan David écrivît :
Ce n'est que parceque ces environnements sont trop limités pour tirer
partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
Il y a 20 ans, on avait pas de clefs USB, pas de DBus, pas de *kit ni de
systemd. Et il me semble qu'on ne pouvait pas sauver ses fichiers sur
disquettes depuis un terminal X :-).
--
« Ceci n'est pas une signature. » — René Magritte (Apocryphe)
Ce n'est que parceque ces environnements sont trop limités pour tirer partie de la puissance de l'OS.
Les terminaux X existaient déjà il y a plus de 20 ans...
Il y a 20 ans, on avait pas de clefs USB, pas de DBus, pas de *kit ni de systemd. Et il me semble qu'on ne pouvait pas sauver ses fichiers sur disquettes depuis un terminal X :-).
-- « Ceci n'est pas une signature. » — René Magritte (Apocryphe)
