Re: [uml-devel] Re: Patch for buffer overrun in serial/console device logic

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

Alle 03:49, sabato 11 ottobre 2003, Jeff Dike ha scritto:
> doug@easyco.com said:
> > The code itself involves a lot of extra parameters from kernel to user
> >  space as things like the current user aren't propogated down.  I
> > personally think that our current patch set is "100% ugly" and would
> > not  consider posting it as-is.  If people are interested in
> > transparent  numeric UID/GID to hostfs, then I would be happy to clean
> > up what we  have and submit it.
>
> OK, that ain't the way to do it.  Anything that involves passing a parallel
> set of creds through VFS will cause Al Viro to lop my head off.  Since I'm
> somewhat attached to it, I will not propose such a thing, no matter how
> cleaned up it is.
>
> What would work is to store the creds in a separate container of some sort
> on the host, and reference that inside hostfs when doing permission checks.
>
> This is more or less what UMSDOS does, from what I understand, and it keeps
> the nastiness contained within hostfs.
>
> That journalling is a neat idea, BTW.
This are my very humble opinions, just my 2 cents, however let's go.
1)a solution involving a setuid UML is just wrong. Something lighter is 
obviously welcome.
2) so, on the host, all files must have the same permissions, and the same 
owner, when you use hostfs as rootfs. I.e., the uid and the gid will have to 
be the same as the ones UML runs with. And the permission will have to be 
fixed ones. For instance, for files we have fumask=644 by default, and it can 
be set to anything not stricter than 600; for dirs, dumask=755 by default, 
and it mustn't be stricter than 700. If and only if you want to have fun, you 
can check if a file has u+x permission and give u+x(or a+x, it's matter of 
taste/security) on the host. These params can be set on the linux command 
line; a mount option can exist, but it must be "bounded" by the boot 
option(the same way you can specify the rootfs option and then restrict even 
more the mount).
Then, there can be UMSDOS-like stuff.
This is the only way to make possible things such as a file that inside UML 
has perms=000 and is readable by root. In this case, hostfs is a true 
filesystem.
3)But, there is a separate issue: accessing the host files, i.e. when you want 
to watch on files existing on the host(so you can't change freely their 
permission). This is a completely different case! Here you can't even suppose 
you can write the UMSDOS like permission-holding file.
So here root has limited permission. My idea here is to make things follow 
some extended semantic, like the 2.6 security models: neither there root has 
all powers, or seeming a NFS mount(neither there root has full permissions). 
It's just a start of idea, but *could* be interesting.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel