Je suis en train de tester la gravure de CD sur ma Debian Testing et je
ne sais pas trop comment gérer les problèmes de permissions avec
cdrecord pour pouvoir graver en tant que simple utilisateur.
En ce moment j'utilise k3b qui fonctionne très bien mais qui me renvoie
les messages suivants :
/usr/bin/cdrecord:cannot set RR-scheduler
/usr/bin/cdrecord:canot set priority using setpriority()
WARNING:this causes a high risk for buffer underuns
J'ai lu sur les forums deux choses contradictoires :
1) il faut éviter de mettre des bits SUID
2) mettre le bit SUID de cdrecord
Qui doit-je écouter ?
Merci,
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Je suis en train de tester la gravure de CD sur ma Debian Testing et je ne sais pas trop comment gérer les problèmes de permissions avec cdrecord pour pouvoir graver en tant que simple utilisateur.
En ce moment j'utilise k3b qui fonctionne très bien mais qui me renvoie les messages suivants : /usr/bin/cdrecord:cannot set RR-scheduler /usr/bin/cdrecord:canot set priority using setpriority() WARNING:this causes a high risk for buffer underuns
Ça, c'est parce qu'il tente de « renicer » le processus pour éviter les problèmes de buffer dûs à des retard de dispatching.
Soit vous avez une machine assez puissante et vous pouvez ignorer ce message. Soit vous avec un truc comme « burnproof » ou autre et vous pouvez ignorer ce message. Soit vous réduisez la vitesse de gravure pour éviter ce problème. Soit vous faites de l'acrobatie et vous changez la priorité depuis une session root ...
J'ai lu sur les forums deux choses contradictoires : 1) il faut éviter de mettre des bits SUID 2) mettre le bit SUID de cdrecord
Mettre un bit suid est toujours un rsque potentiel pur la sécurité du système. Mais il faut parfois savoir vivre dangereusement : si c'est votre machine de bureau, vous pouvez prendre le risque (je suis sûr que vous en prenez bie d'autre). Si c'est sur un serveur en production, peut-être devrez-vous envisager la chose avec davantage de circonspection...
Je suis en train de tester la gravure de CD sur ma Debian Testing et
je
ne sais pas trop comment gérer les problèmes de permissions avec
cdrecord pour pouvoir graver en tant que simple utilisateur.
En ce moment j'utilise k3b qui fonctionne très bien mais qui me
renvoie
les messages suivants :
/usr/bin/cdrecord:cannot set RR-scheduler
/usr/bin/cdrecord:canot set priority using setpriority()
WARNING:this causes a high risk for buffer underuns
Ça, c'est parce qu'il tente de « renicer » le processus pour éviter les
problèmes de buffer dûs à des retard de dispatching.
Soit vous avez une machine assez puissante et vous pouvez ignorer ce
message.
Soit vous avec un truc comme « burnproof » ou autre et vous pouvez
ignorer ce message.
Soit vous réduisez la vitesse de gravure pour éviter ce problème.
Soit vous faites de l'acrobatie et vous changez la priorité depuis une
session root ...
J'ai lu sur les forums deux choses contradictoires :
1) il faut éviter de mettre des bits SUID
2) mettre le bit SUID de cdrecord
Mettre un bit suid est toujours un rsque potentiel pur la sécurité du
système. Mais il faut parfois savoir vivre dangereusement : si c'est
votre machine de bureau, vous pouvez prendre le risque (je suis sûr que
vous en prenez bie d'autre). Si c'est sur un serveur en production,
peut-être devrez-vous envisager la chose avec davantage de
circonspection...
Je suis en train de tester la gravure de CD sur ma Debian Testing et je ne sais pas trop comment gérer les problèmes de permissions avec cdrecord pour pouvoir graver en tant que simple utilisateur.
En ce moment j'utilise k3b qui fonctionne très bien mais qui me renvoie les messages suivants : /usr/bin/cdrecord:cannot set RR-scheduler /usr/bin/cdrecord:canot set priority using setpriority() WARNING:this causes a high risk for buffer underuns
Ça, c'est parce qu'il tente de « renicer » le processus pour éviter les problèmes de buffer dûs à des retard de dispatching.
Soit vous avez une machine assez puissante et vous pouvez ignorer ce message. Soit vous avec un truc comme « burnproof » ou autre et vous pouvez ignorer ce message. Soit vous réduisez la vitesse de gravure pour éviter ce problème. Soit vous faites de l'acrobatie et vous changez la priorité depuis une session root ...
J'ai lu sur les forums deux choses contradictoires : 1) il faut éviter de mettre des bits SUID 2) mettre le bit SUID de cdrecord
Mettre un bit suid est toujours un rsque potentiel pur la sécurité du système. Mais il faut parfois savoir vivre dangereusement : si c'est votre machine de bureau, vous pouvez prendre le risque (je suis sûr que vous en prenez bie d'autre). Si c'est sur un serveur en production, peut-être devrez-vous envisager la chose avec davantage de circonspection...
