From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: jdike@addtoit.com
Subject: Re: [uml-devel] Exactly what is wanted with hostfs UID/GID operation
Date: Fri, 17 Oct 2003 16:28:57 +0200 [thread overview]
Message-ID: <200310171358.20666.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <3F8B2B6E.30709@easyco.com>
Answering to a previous message of Jeff Dike
At 03:49, 11 Oct 2003, Jeff Dike wrote:
> 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.
I don't agree. Al Viro doesn't matter here. The only more params to pass are
from hostfs_kern.c to hostfs_user.c. Stop. Also, since we are in process
context inside hostfs_kern.c, we can also read current very easily (even if we
should rely on VFS permission handling as much as possible). By the way, if
you want to manage the UMSDOS-like db, then you need to pass exactly the same
params down.
**Security risks!**
Besides, even with the UMSDOS-like db, you still need to avoid as much as
possible to create root-owned files on the host. It's always a security risk,
even if it's not that easy to exploit: for instance, let's look at the man
page of modutils:
By default, modutils will reject attempts to use a module that
is not owned by root.
Luckily, you need write access to the /lib/modules path to exploit this, but
it's not a good thing anyway. So if we remove this possibility, it's a better
world for all us.
--
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 sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2003-10-19 13:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-13 22:47 [uml-devel] Exactly what is wanted with hostfs UID/GID operation Doug Dumitru
2003-10-17 14:28 ` BlaisorBlade [this message]
2003-10-22 17:54 ` BlaisorBlade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310171358.20666.blaisorblade_spam@yahoo.it \
--to=blaisorblade_spam@yahoo.it \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox