linux-um archives
 help / color / mirror / Atom feed
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

  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