En particulier, beaucoup de fichiers de config appartiennent à root mais font également partie d'un groupe, ce afin que les utilisateurs autorisés puissent modifier ce qui relève de leurs prérogatives.
Il faut aussi tenir compte des pseudo-users, tels que postgresql, qui est assez tâtillon sur les droits d'accès.
Bref, si un script d'installation m'avait fait ce coup-là, ça m'aurait mis de très mauvaise humeur ...
C'est affreux parce qu'il y a bon nombre de gens qui pensent que l'on ne peut pas faire autrement que de passer root dès lors qu'UNIX dresse la moindre barrière ! "Bah oui, j'ai été obligé de défoncer la porte puisqu'elle était fermée à clef ...".
Ce post-ci, dans lequel l'auteur a au moins le mérite d'être clair sur ses intentions, est assez révélateur de ce qui doit se passer dans la tête de pas mal de monde : https://linuxfr.org/forums/15/22167.html
Et c'est inquiétant parce que cela confirme la probabilité d'un grand danger avec l'expansion du système dans le grand public : la faille de sécurité majeure viendra de l'utilisateur.
Et oui cela a tellement etait bien defini que c'est tout plein d'erreurs, d'inconsistances et de manques.
CTJ (Comme Ton Journal) ? /o\
Il y a des formules incorrectes, qui si elles sont implementees tel que decrites dans ce standard, vont faire apparaitre de serieux problemes mentaux, securitaire et environnemental
Punaise ! Ca fout les jetons !
Honte a ceux qui encensait et continue de d'encenser les formules de OOXML sans avoir lu leurs definitions
Je vais être honnête, je n'ai encore lu ni ODF, ni OOXML en entier et je ne connais pas beaucoup de gens qui l'aient fait. Le fait que PasBill n'ait pas encore réagi laisserait à penser, à priori, que tout cela est vrai, mais présenté de cette façon, je ne suis pas sûr que l'on favorise l'adoption du premier.
Ce qui est malheureux, c'est d'être obligé d'exhiber ces dangers-là pour faire réagir le quidam, alors que le véritable enjeu est quand même de pouvoir certifier que le format ne pourra pas se faire enfermer à postériori.
Une fois que ceci est dit, et étant donné que je suis déjà entièrement gagné à la cause de l'ODF, j'aimerais bien savoir si de telles faiblesses ont déjà été détectées de son coté aussi, ou si personne ne creuse pour le moment ...
Tiens, ce serait marrant, ça : la GNU Font !
Tout plein de gentils moines typographistes tous en rang à respecter une belle charte graphique pour faire une fonte officielle complète ...
Ah ... Google me souffle à l'oreillette que
1) ça existe déjà,
2) ° Bloub °
3) C'est en bitmap
4) Ce n'est toujours pas complet
C'est surtout de l'unicode que tu essaies de faire apparaître, en l'occurence ! Si tu utilises les entités HTML (&#xxx;), effectivement, le charset en entête ne sert à rien.
Par contre, ne rêve pas, tu ne pourras pas afficher la totalité des caractères de la planète (il n'y a qu'a imaginer le temps qu'il faudrait à une personne pour coder 65536 caractères dans un seul fichier de police).
Technologies de l'information . Format de document ouvert pour applications de bureau (OpenDocument) v1.0
...
Mode dépose de fichier Vous devez utiliser le modèle de saisie de commentaires au format Word (.doc de 30Ko). Si vous ne l'avez pas déjà téléchargé cliquez ici
En fait, il faut que tu mettes un peu les doigts dans UNIX et surtout que tu oublies toutes les habitudes Windows : la copie intégrale, secteur-à-secteur, d'un disque vers un autre, tu peux le faire en une seule commande sous Unix : dd. Et encore, dd n'est là que pour suivre un temps soi peu le processus, mais en fait, copier le contenu d'un /dev/hd- vers un autre suffit à effectuer cette opération.
Les principales raisons pour lesquelles on ne le fait pratiquement jamais sont :
1) La duplication de la table des blocs défectueux du disque source qui ne correspondent bien sûr pas à ceux du disque destination. Ceci se résout en relançant un fsck -cc.
2) Les géométries des disques qui, eux, ne sont en général jamais du même modèle.
3) Le fait que sous Unix, tout est fichier. Il suffit donc de tout copier de filesystem à filesystem et de rappeler lilo ou grub depuis un liveCD pour résoudre le problème en entier.
Pour le reste, c'est de la redondance de machine qu'il faut faire si tu veux faire de la tolérance de panne. Au moins tu assures les défaillances matérielles dans le lot et le tout te coûte guère plus chère que des licences de logiciels dédiés.
En gros, si quelqu'un flingue une machine, une autre est déjà en ligne pour prendre le relais dans la milliseconde, le temps que tu répares la première. Même si UNIX permet de presque tout faire, y compris le genre d'accrobaties dont tu parles, on ne dépanne pas une voiture à 130 sur l'autoroute ...
Bon, en fait, je dis GTK comme ça, mais c'est loin d'être la bibliothèque la plus facile à utiliser ! Par contre, elle est bien documentée ...
Sinon, je veux dire que si tu comptes utiliser deux consoles, il faudra déjà ouvrir toi-même ces deux consoles. C'est normal dans le cas de la première puisque c'est depuis cette console que tu vas lancer ton programme. En outre, les flux d'entrée et de sortie seront ouverts pour toi.
Ensuite, pour gérer une deuxième console, essaie de voir comment on peut écrire dedans. La solution, c'est que chaque console est reliée à un fichier spécial (un /dev) qui permet de communiquer avec.
Plus précisément : dans le cas de terminaux physiques réels, ceux-ci sont en général reliés sur le port série, il faut donc envoyer des données sur ce port pour qu'elles apparaissent sur le terminal. Pour ce faire, on écrit dans /dev/ttyS0, par exemple.
Quand on utilise des terminaux virtuels en nombre indéfini depuis un serveur X, ils utilisent des fichiers spéciaux qui se comportent comme des pipes dans /dev/pts/... qui simulent le canal normalement emprunté.
Essaie d'ouvrir un terminal, puis un second. Dans le deuxième, tapes tty. Tu sauras à quel fichier ton xterm est attaché. Par exemple /dev/pts/1
Ensuite, depuis le premier, essaie de taper « echo "Bonjour" > /dev/pts/1 » et regarde ce qu'il se passe. Note : il se peut que tu n'aies pas les droits pour le faire.
L'idée est donc d'utiliser des fopen() ordinaires pour ouvrir des fichiers en lecture et écriture vers ce /dev et dont tu noterais les descripteurs « auxin » et « auxout », par exemple (par analogie avec stdin et stdout).
Ensuite, tu choisis la console dans laquelle tu veux travailler et tu les gère toutes deux de la même façon.
'faudrait que tu nous dises exactement ce que ton prof' attend de toi.
Attention, quand je dis graphique, c'est très basique; j'ai besoin de représenter un schéma de distribution électrique.
Oui, mais ça doit quand même être graphique (c'est-à-dire utiliser l'interface) ou bien est-ce que tu dois dessiner un environnement dans une console texte ? Parce que l'approche à avoir va être radicalement différente.
Dans le premier cas, tu vas ouvrir une connexion vers le serveur X ou exploiter une bibliothèque toute faite comme GTK ou Qt, gérer des événements, etc. tout en continuant à lire et écrire dans stdin/stdout pour dialoguer avec l'utilisateur.
Dans le second, tu ne travailleras qu'avec des flux type stdin/stdout mais il te faudra toi-même ouvrir un terminal et le fichier spécial qui lui est associé.
1) Faire des références mutuelles entre deux classes, çai mal. Je pense même qu'en Java, par exemple, ce ne serait pas possible (je me trompe peut-être, que les experts ne m'en veuillent pas). En général, cela traduit une erreur de conception.
2) Tu ne peux bien sûr pas définir un objet de chaque type dans l'autre classe, par contre tu peux effectivement utiliser une référence ou un pointeur (ce qui est pratique pour les listes chaînées). Sauf qu'une classe étant définie après l'autre, au moment où tu définis « voiture », ton compilo ne sait pas encore que « Personne » est une classe, donc un type de données.
Solution : utiliser des prototypes.
class voiture;
class Personne;
class voiture { ...
Mais je répète : les références circulaires, en général, sapuduku.
je passe à la repêche un examen de programmation système (demain matin 8h30...)
Ah, ouais ! quand même ! :-)
2/Une ecriture sur un tube sans lecteurs en mode bloquant provoque l'envoi du signal SIGPIPE au processus ecrivain, même si celui-ci a la place d'ecrire dans le tube.
Vrai (pas sur)
Non. C'est même à cela que servent les tubes nommés. A se donner rendez-vous de manière asynchrone. Par contre, il y a des chances de se prendre un SIGPIPE si le lecteur REFERME son handler.
3/ Un processus n'effectuant aucun appel systeme n'est pas interruptible par un signal, car les signaux ne sont délivrés que lors du passage en mode noyau.
Faux (on peux toujours envoyer un kill -9)
Pas seulement. Même si tu fais un while(1);, ton processus pourra être préempté ! C'est à ça que servent les signaux. Et c'est pour cela que l'on peut faire un Ctrl-C dessus.
4/ La terminaison d'un processus provoque la terminaison de tous ses fils. Vrai (quoique vérifie dans quel cas il passe zombi et dans quel cas il quitte proprement)
Oui, c'est vrai, mais le processus peut prendre les devants pour s'émanciper. Par contre, cela n'a rien à voir avec les zombies, qui sont des processus morts mais qui ne peuvent être incinérés avant que le père n'ait reconnu le corps.
6/ En terme d'espace disque, la création réussie d'un lien physique (par le shell: ln titi toto ou par l'appel link) est plus coûteuse que la création réussie d'un lien symbolique.
Vrai (12 octet contre 14k pour le lien physique)
Quoi ? O_O
1/Expliquer pourquoi il est en général préférable d'utiliser les fonctions d'entrées-sorties de haut niveau plutot que celle de bas niveau? Meilleur perf, meilleures possibilité donnée au compilo pour optimiser le tout.
Pas le compilateur, mais le système lui-même. En particulier, on permet au processus de rester en userland le maximum du temps et de limiter les appels au noyau.
2/ Qu'est-ce qu'une fonction réentrante? Illustrer sur un exemple le type de problème que peut poser l'utilisation de fonctions non réentrantes.
Si mes souvenirs sont bon, c'est une fonction qui repartira au même endroit si elle a été interrompue par un signal.
Non. C'est une fonction qui, sans être explicitement récursive, sera quand même directement ou indirectement dépendante d'elle-même, ce qui fait qu'elle se mordra la queue. Exemple à la con :
int fprintf (FILE * f, char * message)
{
if (f) /* Fichier ouvert ? */
{
Ecrire message
}
else fprintf (stderr,"Erreur : fichier non ouvert");
}
3/ Quelle différence y'a-t-il entre attente active et attente passive? Donner un exemple de chacune des deux.
Dans quel contexte ?
sleep (attente passive)
select(attente active)
Non plus. Ces deux fonctions sont toutes les deux passives et attendent le feu vert du système pour se réveiller. Une attente active est lorsque l'on provoque soit même une temporisation, ou bien lorsqu'on boucle bêtement en attendant qu'une condition soit remplie :
while (!feu_vert); /* Attend le bon moment */.
Pas la peine de dire que le programme en question va bouffer 100% du CPU.
1/ Quels appels systèmes ou bibliothèque pourrait-on utiliser pour ecrire un programme dont le lancement équivaut à ls rep? Quels sont les permissions nécessaire pour que cette commande réussise?
getdents()
man getdents :
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface.
3/ Que peut-on en déduire pour les permissions positionnées sur le répertoire rep?
Je vois pas comment c'est possible.
Parce que si il peux lister c'est qu'il a les droits x (traverser le répertoire) et r (lire la liste des fichiers)
Et ls -l donnera la liste de ces mêmes fichiers avec un descriptif long.
Essaie chmod 111 rep, c'est marrant.
Les gars ! relisez-vous un peu, quoi. C'était pour un exam !
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 3.
En particulier, beaucoup de fichiers de config appartiennent à root mais font également partie d'un groupe, ce afin que les utilisateurs autorisés puissent modifier ce qui relève de leurs prérogatives.
Il faut aussi tenir compte des pseudo-users, tels que postgresql, qui est assez tâtillon sur les droits d'accès.
Bref, si un script d'installation m'avait fait ce coup-là, ça m'aurait mis de très mauvaise humeur ...
[^] # Re: Petit point !
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 3.
Sans rire, un volontaire pour prévenir Samsung que leur bêtise risque de ternir la marque entière ?
[^] # Re: Voir source du script d'installation
Posté par Obsidian . En réponse au message Ooo s'ouvre en root et non en user normal. Évalué à 4.
Ce post-ci, dans lequel l'auteur a au moins le mérite d'être clair sur ses intentions, est assez révélateur de ce qui doit se passer dans la tête de pas mal de monde : https://linuxfr.org/forums/15/22167.html
Et c'est inquiétant parce que cela confirme la probabilité d'un grand danger avec l'expansion du système dans le grand public : la faille de sécurité majeure viendra de l'utilisateur.
[^] # Re: youpi youpi matin!
Posté par Obsidian . En réponse au journal linuxfr dans télématin .... Évalué à 2.
(je poste mon troll en avance parce que demain je serai très occupé).
# Use The Shell, Luke
Posté par Obsidian . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 3.
grep / grep -v
grep -v / grep
cut -b -15
grep
# Le jour du troll, c'est après-demain ...
Posté par Obsidian . En réponse au journal Une nouvelle raison de refuser Microsoft openXML. Évalué à 2.
CTJ (Comme Ton Journal) ? /o\
Punaise ! Ca fout les jetons !
Je vais être honnête, je n'ai encore lu ni ODF, ni OOXML en entier et je ne connais pas beaucoup de gens qui l'aient fait. Le fait que PasBill n'ait pas encore réagi laisserait à penser, à priori, que tout cela est vrai, mais présenté de cette façon, je ne suis pas sûr que l'on favorise l'adoption du premier.
Ce qui est malheureux, c'est d'être obligé d'exhiber ces dangers-là pour faire réagir le quidam, alors que le véritable enjeu est quand même de pouvoir certifier que le format ne pourra pas se faire enfermer à postériori.
Une fois que ceci est dit, et étant donné que je suis déjà entièrement gagné à la cause de l'ODF, j'aimerais bien savoir si de telles faiblesses ont déjà été détectées de son coté aussi, ou si personne ne creuse pour le moment ...
[^] # Re: ...
Posté par Obsidian . En réponse au journal je sais pas si quelqu'un l'a déja faite aujourd'hui.... Évalué à 2.
http://www.jesuismort.com/
Je connaissais pas (2005 apparement).
[^] # Re: code ascii
Posté par Obsidian . En réponse au message Lister tout les caractères existant.. Évalué à 2.
Tiens, ce serait marrant, ça : la GNU Font !
Tout plein de gentils moines typographistes tous en rang à respecter une belle charte graphique pour faire une fonte officielle complète ...
Ah ... Google me souffle à l'oreillette que
1) ça existe déjà,
2) ° Bloub °
3) C'est en bitmap
4) Ce n'est toujours pas complet
http://czyborra.com/unifont/HEADER.html
[^] # Re: code ascii
Posté par Obsidian . En réponse au message Lister tout les caractères existant.. Évalué à 2.
Voir plutôt du coté de :
http://fr.wikipedia.org/wiki/UTF-8
http://fr.wikipedia.org/wiki/Unicode
et voire même
$ man unicode
Par contre, ne rêve pas, tu ne pourras pas afficher la totalité des caractères de la planète (il n'y a qu'a imaginer le temps qu'il faudrait à une personne pour coder 65536 caractères dans un seul fichier de police).
[^] # Re: ils sont de retour !
Posté par Obsidian . En réponse au journal dell+ubuntu pour le reste du monde. Évalué à 3.
# Format de l'enquête
Posté par Obsidian . En réponse à la dépêche Enquêtes publiques probatoires de l'AFNOR concernant OOXML et ODF. Évalué à 10.
Mouais : y a encore du travail, quoi ! :-)
[^] # Re: Mondo Rescue
Posté par Obsidian . En réponse au message Ghost à chaud sous linux. Évalué à 4.
Les principales raisons pour lesquelles on ne le fait pratiquement jamais sont :
1) La duplication de la table des blocs défectueux du disque source qui ne correspondent bien sûr pas à ceux du disque destination. Ceci se résout en relançant un fsck -cc.
2) Les géométries des disques qui, eux, ne sont en général jamais du même modèle.
3) Le fait que sous Unix, tout est fichier. Il suffit donc de tout copier de filesystem à filesystem et de rappeler lilo ou grub depuis un liveCD pour résoudre le problème en entier.
Pour le reste, c'est de la redondance de machine qu'il faut faire si tu veux faire de la tolérance de panne. Au moins tu assures les défaillances matérielles dans le lot et le tout te coûte guère plus chère que des licences de logiciels dédiés.
En gros, si quelqu'un flingue une machine, une autre est déjà en ligne pour prendre le relais dans la milliseconde, le temps que tu répares la première. Même si UNIX permet de presque tout faire, y compris le genre d'accrobaties dont tu parles, on ne dépanne pas une voiture à 130 sur l'autoroute ...
[^] # Re: man diff
Posté par Obsidian . En réponse au message créer un patch pour rajouter des sous répertoire. Évalué à 2.
[^] # Re: Plus d'infos
Posté par Obsidian . En réponse au message Gérer deux sorties écran avec un programme en C. Évalué à 5.
Sinon, je veux dire que si tu comptes utiliser deux consoles, il faudra déjà ouvrir toi-même ces deux consoles. C'est normal dans le cas de la première puisque c'est depuis cette console que tu vas lancer ton programme. En outre, les flux d'entrée et de sortie seront ouverts pour toi.
Ensuite, pour gérer une deuxième console, essaie de voir comment on peut écrire dedans. La solution, c'est que chaque console est reliée à un fichier spécial (un /dev) qui permet de communiquer avec.
Plus précisément : dans le cas de terminaux physiques réels, ceux-ci sont en général reliés sur le port série, il faut donc envoyer des données sur ce port pour qu'elles apparaissent sur le terminal. Pour ce faire, on écrit dans /dev/ttyS0, par exemple.
Quand on utilise des terminaux virtuels en nombre indéfini depuis un serveur X, ils utilisent des fichiers spéciaux qui se comportent comme des pipes dans /dev/pts/... qui simulent le canal normalement emprunté.
Essaie d'ouvrir un terminal, puis un second. Dans le deuxième, tapes tty. Tu sauras à quel fichier ton xterm est attaché. Par exemple /dev/pts/1
Ensuite, depuis le premier, essaie de taper « echo "Bonjour" > /dev/pts/1 » et regarde ce qu'il se passe. Note : il se peut que tu n'aies pas les droits pour le faire.
L'idée est donc d'utiliser des fopen() ordinaires pour ouvrir des fichiers en lecture et écriture vers ce /dev et dont tu noterais les descripteurs « auxin » et « auxout », par exemple (par analogie avec stdin et stdout).
Ensuite, tu choisis la console dans laquelle tu veux travailler et tu les gère toutes deux de la même façon.
# Plus d'infos
Posté par Obsidian . En réponse au message Gérer deux sorties écran avec un programme en C. Évalué à 5.
Oui, mais ça doit quand même être graphique (c'est-à-dire utiliser l'interface) ou bien est-ce que tu dois dessiner un environnement dans une console texte ? Parce que l'approche à avoir va être radicalement différente.
Dans le premier cas, tu vas ouvrir une connexion vers le serveur X ou exploiter une bibliothèque toute faite comme GTK ou Qt, gérer des événements, etc. tout en continuant à lire et écrire dans stdin/stdout pour dialoguer avec l'utilisateur.
Dans le second, tu ne travailleras qu'avec des flux type stdin/stdout mais il te faudra toi-même ouvrir un terminal et le fichier spécial qui lui est associé.
# Select ?
Posté par Obsidian . En réponse au message Mon buffer de socket se remplit il ?. Évalué à 3.
[^] # Re: GNU coreutils
Posté par Obsidian . En réponse au message code source STTY. Évalué à 5.
[^] # Re: Hum, réfléchis
Posté par Obsidian . En réponse au message concatenation de chaine. Évalué à 4.
C'est vrai que les char mallow(), c'est bien meilleur. Surtout autour d'un feu de camp ! :-)
[^] # Re: Et l'eau !
Posté par Obsidian . En réponse au journal Mettre de l'huile dans l'eau des pâtes ?. Évalué à 3.
[^] # Re: Troll de compet'
Posté par Obsidian . En réponse au journal BlueGene/P...enfin le petaflop !. Évalué à 1.
# Décoration des fonctions.
Posté par Obsidian . En réponse au message librairie synamique compilé en C linké en c++. Évalué à 4.
Essaie de mettre ton header de lib à l'intérieur de
extern "C"
{
#include "malib.h"
}
# Relis.
Posté par Obsidian . En réponse au message fichier d'en tête fich.h. Évalué à 4.
https://linuxfr.org/forums/20/22392.html
1) Faire des références mutuelles entre deux classes, çai mal. Je pense même qu'en Java, par exemple, ce ne serait pas possible (je me trompe peut-être, que les experts ne m'en veuillent pas). En général, cela traduit une erreur de conception.
2) Tu ne peux bien sûr pas définir un objet de chaque type dans l'autre classe, par contre tu peux effectivement utiliser une référence ou un pointeur (ce qui est pratique pour les listes chaînées). Sauf qu'une classe étant définie après l'autre, au moment où tu définis « voiture », ton compilo ne sait pas encore que « Personne » est une classe, donc un type de données.
Solution : utiliser des prototypes.
class voiture;
class Personne;
class voiture { ...
Mais je répète : les références circulaires, en général, sapuduku.
[^] # Re: Réponse (a vérifier)
Posté par Obsidian . En réponse au message Questions d'exam. Évalué à 2.
Le second, c'est qu'il ne consomme pas d'inode supplémentaire.
C'est bien le même fichier référencé deux fois.
[^] # Re: Réponse (a vérifier)
Posté par Obsidian . En réponse au message Questions d'exam. Évalué à 2.
[^] # Re: Réponse (a vérifier)
Posté par Obsidian . En réponse au message Questions d'exam. Évalué à 2.
Ah, ouais ! quand même ! :-)
Non. C'est même à cela que servent les tubes nommés. A se donner rendez-vous de manière asynchrone. Par contre, il y a des chances de se prendre un SIGPIPE si le lecteur REFERME son handler.
Pas seulement. Même si tu fais un while(1);, ton processus pourra être préempté ! C'est à ça que servent les signaux. Et c'est pour cela que l'on peut faire un Ctrl-C dessus.
Oui, c'est vrai, mais le processus peut prendre les devants pour s'émanciper. Par contre, cela n'a rien à voir avec les zombies, qui sont des processus morts mais qui ne peuvent être incinérés avant que le père n'ait reconnu le corps.
Quoi ? O_O
Pas le compilateur, mais le système lui-même. En particulier, on permet au processus de rester en userland le maximum du temps et de limiter les appels au noyau.
Non. C'est une fonction qui, sans être explicitement récursive, sera quand même directement ou indirectement dépendante d'elle-même, ce qui fait qu'elle se mordra la queue. Exemple à la con :
int fprintf (FILE * f, char * message)
{
if (f) /* Fichier ouvert ? */
{
Ecrire message
}
else fprintf (stderr,"Erreur : fichier non ouvert");
}
Non plus. Ces deux fonctions sont toutes les deux passives et attendent le feu vert du système pour se réveiller. Une attente active est lorsque l'on provoque soit même une temporisation, ou bien lorsqu'on boucle bêtement en attendant qu'une condition soit remplie :
while (!feu_vert); /* Attend le bon moment */.
Pas la peine de dire que le programme en question va bouffer 100% du CPU.
man getdents :
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface.
Essaie chmod 111 rep, c'est marrant.
Les gars ! relisez-vous un peu, quoi. C'était pour un exam !