Re: [vhffs] vhost et droits unix

[ Thread Index | Date Index | More vhffs.org/vhffs Archives ]


Salut Sylvain ;

après avoir fait mes premières armes sur la compilation de kernel (youpi !), j'ai réussi à compiler quelques 2.6.39 (la dernière version supportée par le patch que vous proposez sur SVN) et à booter dessus.

Là ou ca se complique, c'est pour appliquer le patch. ca me donne ca :
root@testVM:/usr/src/linux# patch -p0 < tfsyscall-0.2.2-2.6.39.patch
patching file b/fs/namei.c
Hunk #1 FAILED at 2029.
Hunk #2 FAILED at 2658.
2 out of 2 hunks FAILED -- saving rejects to file b/fs/namei.c.rej
patching file b/fs/open..c
Hunk #1 FAILED at 512.
Hunk #2 FAILED at 553.
Hunk #3 FAILED at 1044.
Hunk #4 FAILED at 1071.
4 out of 4 hunks FAILED -- saving rejects to file b/fs/open.c.rej
j'imagine qu'il dit qu'il aime pas trop à quoi ressemble le fichier qu'il essaye de patcher ... et effectivement y'a pas vraiment ce à quoi il s'attend aux lignes en question.
j'ai essayé avec le peu de source que j'ai trouvé (ce n'est pas une mince affaire avec kernel.org qui est down), à savoir :
- ce paquet pour debian : http://packages.debian.org/squeeze-backports/linux-source-2.6.39
- un extract depuis le github de torvald sur le tag 2.6.39 himself : https://github.com/torvalds/linux/tree/v2.6.39
mais ca fait la même dans les 2 cas ...

peux tu me dire s'il y a une subtilité que j'ai manqué (voire plus ...), ou tout simplement à quel kernel précisément est destiné ce patch, et surtout où peut-on le récupérer ?
est-ce que ca a été utilisé chez TuxFamily ? où avez-vous pris les sources ?

merci d'avance parce que là je patauge grave et je croyais m'en sortir ...
d'ailleurs comme je prends beaucoup de notes pendant mes essais (avant de refaire tout ca sur notre serveur), on pourra discuter d'apporter des modifs / compléter la doc sur un certain nombre de points (bien que ca se soit bien amélioré depuis 1 an je trouve), notamment sur cette histoire de kernel à patcher.

Laurent.

2011/9/11 Sylvain Rochet <gradator@xxxxxxxxxxxx>
Salut Laurent,


On Sun, Sep 11, 2011 at 04:43:21AM +0200, Laurent Stella wrote:
> Bonsoir ;
>
> d'accord, donc cela reste une vrai problématique. L'utilisateur (pas très
> geek) s'attend à ce que les espaces web soient isolés,

Oh non, c'est plus simple que ça, il n'y comprend rien c'est tout :-)


> ce qui pourrait être le cas avec un umask 007.

Non plus, l'umask c'est juste le mode par défaut lors de la création de
nouveaux fichiers, ce n'est pas valable si l'application fait un chown
derrière. Les clients FTP font pas exemple un chmod après l'upload du
fichier, et je ne parle même pas des accès SSH ou c'est l'utilisateur
qui choisit son umask.


> N'y aurait-il pas un module apache qui ferait comme suphp mais pour
> les fichiers statiques ?

Le module Apache ne changera rien, ce n'est pas Apache qui va lire le
fichier en o+r. Hors contenus statiques et dans ce cas c'est légitime,
le lire directement sur le système de fichier ou via HTTP ne change pas
grand chose ;-)

Par contre, dès que l'utilisateur peut executer n'importe quel binaire,
il aura accès à tous les fichiers en o+r avec son utilisateur, c'est le
cas avec PHP et avec n'importe quel programme. Et c'est juste une
nécessité d'autoriser les utilisateurs à lancer n'importe quoi pour
fournir un service complet.


> je vais regarder le patch kernel rapidement (même si ca ne m'enchante
> pas :-p )

Vu que la seule interface qui reste entre les binaires qui peuvent lire
les fichiers sont les syscalls il ne reste pas beaucoup de possibilités,
la solution est coté kernel, soit via un patch, soit en utilisant les
méchanismes de sécurité intégré au kernel (SElinux, ...).


> en tout cas merci pour ce début de réponse, tu m'as l'air bien seul
> pour assurer le support (et bien plus j'imagine).

Au plaisir ;-)


Sylvain



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/