je cherche (dans un programme C++) à déplacer un fichier d'une partition
à l'autre, ce qui n'est pas possible avec la fonction rename(), qui
renvoit dans ce cas l'erreur "Invalid cross-device link".
J'ai cherché dans google, regardé dans la glib, dans les sources du
programme mv:
* google: recherches infructueuses, je dois être trop bête pour trouver
la requête qui va bien.
* glib: la commande g_rename ne fait rien de plus qu'appeler rename, ce
qui ne m'avance pas :-)
* mv: c'est un peu trop complexe pour un "déplacement de rien du tout" ;-)
C'était inutile de citer tout le message. Par égard à la bande passante...
Le programme ci-dessus n'a rien de plus sécurisé que les deux lignes que j'avais donné (sans prétention).
Elles ne disaient simplement rien sinon une approche. J'ai juste proposé un code qui marche, tu es le bienvenu pour y trouver des failles.
Certes il y a toutes les fioritures requises pour faire une allocation de chaîne mais un appel du programme de la forme :
mymv toto "tata; rm -rf /"
n'est pas plus sécurisé.
Lorsque l'on tape ça au clavier sous root, on est responsable de ce que l'on fait, je le fais rarement parce que ça fait perdre 1/2 heure à tous les utilisateurs du système: booter, redescendre la backup rebooter toussa. On ne le fait que pour voir si la procédure marche. Il y a 2 ou 3 mois, j'upgradais ma debian comme tous les dimanches que dieu fait, ce putain d'apt-get m'a dis que je faisais quelque chose de potentiellement dangereus et m'a demandé de répondre 'yes, do what I say', j'ai du m'y reprendre à plusieurs fois à cause des typos, et boom ! Et merde ! Encore une 1/2 heure de perdue !
Comme le disais volontier notre bon roy Henri IV, backup & restore sont les 2 mammelles de l'informatique.
Il aurait fallu écrire :
#define FORMAT "/bin/mv "%s" "%s""
qui fonctionne aussi avec les noms de fichiers contenant des espaces.
Je n'y avais pas pensé !
D'autre part, les problèmes de sécurité qui peuvent survenir avec les bits suid et sgid seront identiques, qu'on utilise system ou fork/exec.
Non, car ils sont dépendants d'un shell.
C'est à l'administrateur de gérer ce genre de droits. La sécurité est effectivement un critère important mais il ne faut pas non plus tomber dans la paranoia : on n'est pas sous Windows,
Rendons grâce à Manitoo. On peut espérer qu'en le déballant de la boite le système soit assez sécurisé, c'est de la responsabilité de celui qui en charge du système qu'il le demeure.
un rm * ne va pas non plus casser tout le systeme, sauf si les droits sont gérés n'importe comment.
Installer des fichiers sur /bin ou /usr/bin nécessite des droits, on ne peut pas laisser les choses dans un état approximatif.
Un système d'exploitation digne de ce nom fourni des outils et on ne va pas tout ré-écrire chaque fois par peur des chevaux de Troie. Pour ma part, je ne vois pas le mal à appeler une commande externe à partir d'un programme.
Moi non plus, l'important est la confiance que l'on peut avoir dans ces commandes.
La question de départ était une question simple, la réponse que j'y ai apporté était simple.
Oui.
La question ne portait pas sur l'allocation mémoire, la gestion des codes de retour, l'analyse des paramètres ou les traitements de signaux, donc inutile de dériver dans cette voie si ce n'est pour refaire un sempiternel troll à la suite d'une question simple.
Les questions simples devraient-elles impliquer des réponses simples ? On peut penser que l'OP postait une question qui était précise et qi'il était de bon ton de lui apporter une réponse la plus précise possible. Est-ce un troll ? Qui en est à l'origine ? Toi ou moi ?
Il est d'ailleurs très intéressant de constater que les trolls se forment toujours sur les questions simples,
J'ai répondu à une question précise en apportant une réponse précise, qui certes vaut ce qu'elle vaut et je remercie ceux qui ont apporté des critiques constructives, je n'en suis pas encore à dire 'ma solution est aussi bien que la tienne', ça je te le laisse sans regret.
jamais sur les complexes... Ca doit être un signe...
Ca fait même pas une semaine que je traîne sur fr.comp.os.unix, alors, s'il te plait, pose moi clairement une question complexe !
-- http://harpo.free.fr/
Fred wrote:
(...)
Alors là il faut qu'on m'explique !!
C'était inutile de citer tout le message. Par égard à la bande
passante...
Le programme ci-dessus n'a rien de plus sécurisé que les deux lignes
que j'avais donné (sans prétention).
Elles ne disaient simplement rien sinon une approche. J'ai juste proposé
un code qui marche, tu es le bienvenu pour y trouver des failles.
Certes il y a toutes les
fioritures requises pour faire une allocation de chaîne mais un appel
du programme de la forme :
mymv toto "tata; rm -rf /"
n'est pas plus sécurisé.
Lorsque l'on tape ça au clavier sous root, on est responsable de ce que
l'on fait, je le fais rarement parce que ça fait perdre 1/2 heure à
tous les utilisateurs du système: booter, redescendre la backup
rebooter toussa. On ne le fait que pour voir si la procédure marche.
Il y a 2 ou 3 mois, j'upgradais ma debian comme tous les dimanches que
dieu fait, ce putain d'apt-get m'a dis que je faisais quelque chose de
potentiellement dangereus et m'a demandé de répondre 'yes, do what I
say', j'ai du m'y reprendre à plusieurs fois à cause des typos, et
boom ! Et merde ! Encore une 1/2 heure de perdue !
Comme le disais volontier notre bon roy Henri IV, backup & restore sont
les 2 mammelles de l'informatique.
Il aurait fallu écrire :
#define FORMAT "/bin/mv "%s" "%s""
qui fonctionne aussi avec les noms de fichiers contenant des espaces.
Je n'y avais pas pensé !
D'autre part, les problèmes de sécurité qui peuvent survenir avec les
bits suid et sgid seront identiques, qu'on utilise system ou
fork/exec.
Non, car ils sont dépendants d'un shell.
C'est à l'administrateur de gérer ce genre de droits.
La sécurité est effectivement un critère important mais il ne faut pas
non plus tomber dans la paranoia : on n'est pas sous Windows,
Rendons grâce à Manitoo.
On peut espérer qu'en le déballant de la boite le système soit assez
sécurisé, c'est de la responsabilité de celui qui en charge du système
qu'il le demeure.
un rm *
ne va pas non plus casser tout le systeme, sauf si les droits sont
gérés n'importe comment.
Installer des fichiers sur /bin ou /usr/bin nécessite des droits, on ne
peut pas laisser les choses dans un état approximatif.
Un système d'exploitation digne de ce nom
fourni des outils et on ne va pas tout ré-écrire chaque fois par peur
des chevaux de Troie. Pour ma part, je ne vois pas le mal à appeler
une commande externe à partir d'un programme.
Moi non plus, l'important est la confiance que l'on peut avoir dans ces
commandes.
La question de départ était une question simple, la réponse que j'y ai
apporté était simple.
Oui.
La question ne portait pas sur l'allocation
mémoire, la gestion des codes de retour, l'analyse des paramètres ou
les traitements de signaux, donc inutile de dériver dans cette voie si
ce n'est pour refaire un sempiternel troll à la suite d'une question
simple.
Les questions simples devraient-elles impliquer des réponses simples ?
On peut penser que l'OP postait une question qui était précise et qi'il
était de bon ton de lui apporter une réponse la plus précise possible.
Est-ce un troll ? Qui en est à l'origine ? Toi ou moi ?
Il est d'ailleurs très intéressant de constater que les trolls
se forment toujours sur les questions simples,
J'ai répondu à une question précise en apportant une réponse précise,
qui certes vaut ce qu'elle vaut et je remercie ceux qui ont apporté des
critiques constructives, je n'en suis pas encore à dire 'ma solution
est aussi bien que la tienne', ça je te le laisse sans regret.
jamais sur les complexes...
Ca doit être un signe...
Ca fait même pas une semaine que je traîne sur fr.comp.os.unix, alors,
s'il te plait, pose moi clairement une question complexe !
C'était inutile de citer tout le message. Par égard à la bande passante...
Le programme ci-dessus n'a rien de plus sécurisé que les deux lignes que j'avais donné (sans prétention).
Elles ne disaient simplement rien sinon une approche. J'ai juste proposé un code qui marche, tu es le bienvenu pour y trouver des failles.
Certes il y a toutes les fioritures requises pour faire une allocation de chaîne mais un appel du programme de la forme :
mymv toto "tata; rm -rf /"
n'est pas plus sécurisé.
Lorsque l'on tape ça au clavier sous root, on est responsable de ce que l'on fait, je le fais rarement parce que ça fait perdre 1/2 heure à tous les utilisateurs du système: booter, redescendre la backup rebooter toussa. On ne le fait que pour voir si la procédure marche. Il y a 2 ou 3 mois, j'upgradais ma debian comme tous les dimanches que dieu fait, ce putain d'apt-get m'a dis que je faisais quelque chose de potentiellement dangereus et m'a demandé de répondre 'yes, do what I say', j'ai du m'y reprendre à plusieurs fois à cause des typos, et boom ! Et merde ! Encore une 1/2 heure de perdue !
Comme le disais volontier notre bon roy Henri IV, backup & restore sont les 2 mammelles de l'informatique.
Il aurait fallu écrire :
#define FORMAT "/bin/mv "%s" "%s""
qui fonctionne aussi avec les noms de fichiers contenant des espaces.
Je n'y avais pas pensé !
D'autre part, les problèmes de sécurité qui peuvent survenir avec les bits suid et sgid seront identiques, qu'on utilise system ou fork/exec.
Non, car ils sont dépendants d'un shell.
C'est à l'administrateur de gérer ce genre de droits. La sécurité est effectivement un critère important mais il ne faut pas non plus tomber dans la paranoia : on n'est pas sous Windows,
Rendons grâce à Manitoo. On peut espérer qu'en le déballant de la boite le système soit assez sécurisé, c'est de la responsabilité de celui qui en charge du système qu'il le demeure.
un rm * ne va pas non plus casser tout le systeme, sauf si les droits sont gérés n'importe comment.
Installer des fichiers sur /bin ou /usr/bin nécessite des droits, on ne peut pas laisser les choses dans un état approximatif.
Un système d'exploitation digne de ce nom fourni des outils et on ne va pas tout ré-écrire chaque fois par peur des chevaux de Troie. Pour ma part, je ne vois pas le mal à appeler une commande externe à partir d'un programme.
Moi non plus, l'important est la confiance que l'on peut avoir dans ces commandes.
La question de départ était une question simple, la réponse que j'y ai apporté était simple.
Oui.
La question ne portait pas sur l'allocation mémoire, la gestion des codes de retour, l'analyse des paramètres ou les traitements de signaux, donc inutile de dériver dans cette voie si ce n'est pour refaire un sempiternel troll à la suite d'une question simple.
Les questions simples devraient-elles impliquer des réponses simples ? On peut penser que l'OP postait une question qui était précise et qi'il était de bon ton de lui apporter une réponse la plus précise possible. Est-ce un troll ? Qui en est à l'origine ? Toi ou moi ?
Il est d'ailleurs très intéressant de constater que les trolls se forment toujours sur les questions simples,
J'ai répondu à une question précise en apportant une réponse précise, qui certes vaut ce qu'elle vaut et je remercie ceux qui ont apporté des critiques constructives, je n'en suis pas encore à dire 'ma solution est aussi bien que la tienne', ça je te le laisse sans regret.
jamais sur les complexes... Ca doit être un signe...
Ca fait même pas une semaine que je traîne sur fr.comp.os.unix, alors, s'il te plait, pose moi clairement une question complexe !
-- http://harpo.free.fr/
Robert CHERAMY
Salut,
Robert CHERAMY wrote:
je cherche (dans un programme C++) à déplacer un fichier d'une partition à l'autre, ce qui n'est pas possible avec la fonction rename(), qui renvoit dans ce cas l'erreur "Invalid cross-device link". (...)
Avez-vous des idées ? Je n'aurais jamais pensé déclencher un tel thread avec une question si
anodine... Merci de vous donner tant de peine pour moi :-)
Finalement, j'ai laissé tomber le move inter-partitions, j'ai créé mon fichier temporaire dans la partition de destination[1], et fait mon rename() là bas.
Merci
tibob
1. Notre très importante: merci de ne pas lancer un thr...oll sur la sécurité liée à la création du fichier temporaire ;-)
Salut,
Robert CHERAMY wrote:
je cherche (dans un programme C++) à déplacer un fichier d'une
partition à l'autre, ce qui n'est pas possible avec la fonction
rename(), qui renvoit dans ce cas l'erreur "Invalid cross-device link".
(...)
Avez-vous des idées ?
Je n'aurais jamais pensé déclencher un tel thread avec une question si
anodine... Merci de vous donner tant de peine pour moi :-)
Finalement, j'ai laissé tomber le move inter-partitions, j'ai créé mon
fichier temporaire dans la partition de destination[1], et fait mon
rename() là bas.
Merci
tibob
1. Notre très importante: merci de ne pas lancer un thr...oll sur la
sécurité liée à la création du fichier temporaire ;-)
je cherche (dans un programme C++) à déplacer un fichier d'une partition à l'autre, ce qui n'est pas possible avec la fonction rename(), qui renvoit dans ce cas l'erreur "Invalid cross-device link". (...)
Avez-vous des idées ? Je n'aurais jamais pensé déclencher un tel thread avec une question si
anodine... Merci de vous donner tant de peine pour moi :-)
Finalement, j'ai laissé tomber le move inter-partitions, j'ai créé mon fichier temporaire dans la partition de destination[1], et fait mon rename() là bas.
Merci
tibob
1. Notre très importante: merci de ne pas lancer un thr...oll sur la sécurité liée à la création du fichier temporaire ;-)
