1 - La phrase est incomplète : # apt-get install apache2
2 - Quand il y a # ce n’est pas JE mais ROOT
Depuis Root j’ai :
- Créé un repertoire pascalous
- fait chown pascalous:pascalous pascalous
Depuis Pascalous j’ai :
- nano test.txt
- CTRL + O, CTRL + X
- chown www-data:www-data test.txt
=> Permission denied.
De plus, la doc php indique que seul root peut changer les propriétaires. De façon générale, si un système tel que CGI sous environnement suEXEC ou je sais pas quoi fait que Apache lance un processus sous l’utilisateur du propriétaire du fichier appelé, il suffirait à Monsieur hébergé mutualisé x de faire un chmown de ses fichiers vers l’utilisateur y pour pouvoir lancer ses fichiers php sous le propriétaire y et avoir accès aux fichiers de Monsieur y. Ce qui va à l’encontre de ce système, je trouve … Même si des open_basedir interviennent, ce n’est pas une raison …
Ensuite, je suis pas sûr du coup d’avoir compris … Un executable s’execute sous le propriétaire enregistré dans ses droits, ou sous le propriétaire qui l’a démarré ? Car Cluxter, si j’ai bien compris, tu as dit que les init.d sont lancés par Kernel, donc par root, et que du coup ils sont root. Tu n’as pas dit que c’était lié au fichier.
Hier, j’ai rée un fichier python sous pascalous, et je l’ai lancé : la commande TOP m’a bien affiché un processus sous l’utilisateur pascalous. Mais … je l’ai créé avec pascalous et l’ai lancé depuis pascalous. Il aurait fallu que je teste la création et la modification avec l’un et l’autre (pascalous / root).
Je vais voir la doc, je vous tiens au “jus”, surtout que l’histoire des setuid m’intrigue …
Apache est lancé en root car il est lancé par root, pas parce que le fichier appartient à root. Ainsi, il peut utiliser les droits root si besoin (ouverture du port 80, écriture dans les logs, suexec/suphp,…) et créé un « sous-processus » lancé par l’utilisateur www-data. Ainsi, si quelqu’un arrive à exploiter une faille d’apache, il n’aura que les droits de www-data.
Sous quel répertoire principal ?
Hmm … j’etends surtout s’il arrive a exploiter les failles du processus ouvert sous www-data. On est d’accord. Par contre, et ca explique les solutions d’hyper sécurisation, une faille exploité sur le processus principal (je crois le daemon), serait catastrophique.
Sous quel répertoire principal ?[/quote]
Hmmm … je ne sais pas où tu veux en venir mais, je vais étendre :
- mkdir /pascalous
- chown pascalous:pascalous /pascalous
Donc, directement à la racine. Je ne veux pas vous contredire sur un sujet que vous connaissez mieux que moi, mais je reste septique sur le changement de propriétaire. En même temps, que pascalous veuille rendre Momo comme propriétaire de son fichier, je ne vois rien d’illogique … mais je vois surtout ça par rapport au mode php CGI (enfin, plus précisemment 
suExec etc) qui crée un processus Apache sous le même utilisateur que le propriétaire de fichier. Mais il y a (forcément) quelque chose qui m’échappe.
A savoir que pascalous n’a été créé sur le serveur que pour utilisateur de connexion SSH. C’est le seul autorisé, il ne possède pas de dossier personnel, et à priori, aucun fichier. Peut-être le changement de propriétaire ne peut se faire par un utilisateur lamba qu’au sein de son propre dossier utilisateur.
PS : Je suis en train de lire “http://www.siteduzero.com/tutoriel-3-12827-reprenez-le-controle-a-l-aide-de-linux.html?all=1#chap_12745” comme suggéré, mais pour l’instant ça reste très basique (d’ailleurs, je l’avais déjà lu il y a près de 1 ou 2 ans). Vos réponses me sont toutefois très enrichissantes, merci;
Totalement. C’est ce qui est le plus redouté sous Linux, une faille dans un processus exécuté sous l’identité “root”. Si on peut exécuter une commande arbitraire dans un tel processus, alors tout le système tombe (sauf avec les contrôles d’accès obligatoires [abrégé MAC en anglais pour Mandatory Access Control] comme SELinux, AppArmor,…).
Re,
Je veux en venir de te rappeler qu’à la racine tu n’es pas chez toi mais chez root (racine) et que donc pas plus que tu n’as eu le droit de le créer tu n’as le droit de le changer de propriétaire 
[quote=“ggoodluck47”]Re,
Je veux en venir de te rappeler qu’à la racine tu n’es pas chez toi mais chez root (racine) et que donc pas plus que tu n’as eu le droit de le créer tu n’as le droit de le changer de propriétaire [/quote]
Ta démarche est certainement pédagogique, mais c’est un serveur global … tous les utilisateurs sont donc moi en quelque sorte …
Je souhaiterais revenir sur ce point :
J’ai vu dans la doc php que seul root peut changer le OWN d’un fichier (les propriétaires user/group quoi).
Et dans la doc conseillée :
siteduzero.com/tutoriel-3-12 … part_12779
[quote]La commande chown, qui doit être utilisée en tant que root, attend 2 paramètres au moins :[/quote] PS : en tant que root est en souligné
Donc : oui ou non les utilisateurs peuvent utiliser des chown ?
C’est simple à savoir : regarde les droits attribués à ton programme “chown” sur ton système. Rien ne t’empêche d’autoriser ou d’interdire tous les utilisateurs à exécuter chown. Et setuid/setgid peut encore modifier la donne.
Après il a y des programmes qui en étant exécutés par un utilisateur demanderont les droits root, mais ils le demanderont explicitement lorsqu’on tentera de les lancer en tant qu’utilisateur.
chown est binaire. Sinon ses droits sont 755 root:root
Tous les utilisateurs, à priori, sont capables de l’exécuter. D’ailleurs, il reconnait bien la commande quand je ne suis pas dans root, mais il me la refuse (operation not permitted).
Je regarderai pour les setuid je ne vois pas pour l’instant où on peut lui dire (de mémoire, tu avais dit ou j’avais lu que cela permettait à un fichier de s’executer toujours sous le meme utilisateur, quelque soit l’utilisateur l’executant en shell).
Au fait, man et bash n’ont pas l’air de connaitre setuid.
Peut-être l’opération setuid n’est-elle effectuée que par l’executable lui-même, une fois déjà executé ?
Autant pour moi … un chmod modifie le setuid. Il a quand même fallu bien chercher …
Aller … J’avance bien, vais-je enfin comprendre le fonctionnement de l’OS
Je n’ai pas accès à SSH ici car … je l’ai un peu trop “sécurisé”. Je connais même pas le port que j’ai mis ^^. Bref, je n’ai pas encore testé :
Je regarderai, mais à priori, si je tape “apache2 machin” dans la console, une commande s’execute. Or, la commande n’est pas présente dans le fichier conf de bash. Donc, est-ce comme sous Windows, si je veux que mon fichier “momo” soit executé en tapant simplement “momo” dans bash par exemple, je n’ai qu’à enregistrer son dossier dans PATH ? La réponse est presque certaine “oui”
Tu avais dit que Kernel executait les daemons sous root (sous lui-même qui a les pleins pouvoir quoi ^^). J’ai donc cherché à savoir si le plus simplement du monde, tout fichier présent dans init.d serait executé au démarrage de la machine, et si executé sous root.
[quote]init est le premier processus, exécuté par le noyau, qui est père de tous les autres (son PID est donc 1).
Au démarrage, il lance divers scripts contenus dans /etc/init.d/ ou /etc/rc*.d/.
C’est dans le dossier /etc/init.d qu’il faut enregistrer les fichiers à lancer au démarrage. [/quote]
Cette citation semble confirmer mon hypothèse. Donc, si je crée un fichier python dans init.d, sans aucun enregistrement nul part, il sera bien lancé au démarrage de la machine, sous root ? Par contre, n’y a t-il pas d’ordre de priorité (peut-être qu’un executable a besoin qu’un autre daemon soit déjà lancé … ou le lance-t-il lui même à ce moment là ?).
Merci pour vos aides, en complément des lectures que je fais, je crois que je commence à bien cerner certaines choses sur Linux, ce qui m’aide dans ma découverte ;o
hello
il te faut lire les en tête des topic, 1 question par topic
je te conseil aussi de faire un passage sur irc , du coter de freenode
le mieux c’est encore de lire les livre
enfin je dit sa je dit rien
Les règles des forums sont souvent 1 question 1 topic. Le fait de poser plusieurs questions part d’une bonne intention de ne pas créer 50 topics
Je vais voir dans quelle mesure je peux répartir les nouvelles questions. Je vais voir ton irc
a+
Ca c’est parce que tu n’as pas lu le manuel de la commande chmod 
A vrai dire avant de demander comment fonctionne cette commande tu aurais déjà du lire le manuel, tu aurais compris déjà beaucoup de choses par toi-même. Je ne dis pas ça pour être désagréable mais parce que je me suis rendu compte à quel point le manuel et les HOWTO sont terriblement efficaces pour apprendre à maîtriser le système dans ses moindres détails (les HOWTO sont d’une utilité incroyable ! Tu les trouves dans “/usr/share/doc/HOWTO” ; et si tu n’as que la version anglaise tu peux installer le paquet qui te les donnera en français).
C’est vrai … encore aurait-il fallu que je me doute une seconde qu’il existait autre chose que wrx pour chmod … On ne parle que d’eux dans les articles sur le web …
tu peux aussi regarder les référence des manpages en bas qui te renvoye parfois a d’autre élément proche sa peux toujours servir, l’inconvénient du net cêst que tout le monde y poste ce qu’il veux sa devients donc répétitif et sa soule, donc rien de tel qu’un bon livre