public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Christoph Hellwig <hch@infradead.org>,
	Blaisorblade <blaisorblade@yahoo.it>,
	akpm@osdl.org, jdike@addtoit.com, linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [patch 03/12] uml: export getgid for hostfs
Date: Thu, 31 Mar 2005 23:24:40 -0500	[thread overview]
Message-ID: <200503312324.41299.rob@landley.net> (raw)
In-Reply-To: <20050331144026.GA18248@infradead.org>

On Thursday 31 March 2005 09:40 am, Christoph Hellwig wrote:
> > Sorry, I wasn't clear... I read *that* answer, but it says "as mentioned
> > in the discussion about ROOT_DEV", and I couldn't find it.
>
> That'd be:
>
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=110664428918937&w=2

As the only user who seems to be crazy enough to regularly run UML with a 
hostfs root (ala "./linux rootfstype=hostfs rw init=/bin/sh"), I'd just like 
to say that I'm fairly certain I'm _not_ using ROOT_DEV special casing (my 
root files actually do belong to root, I'm just borrowing the parent's 
filesystem to avoid the trouble of setting up a whole filesystem under 
loopback.)

And actually, the ROOT_DEV hack wouldn't help me, because my project is using 
a dirty trick where I make a loopback mounted ext2 image (which could easily 
be ramfs or tmpfs if my project didn't need 500 megs of scratch space), 
--bind mount all the directories from the parent I need into it, and chroot 
into it.  (Thus I have the parent's binaries and libraries, but the rest is 
writeable space I can mknod and chown and such in.)  This is done with a 
trivial shell script, the guts of which are:

-----------------------
for i in /*
do
  i="${i:1}"
  if [ "$i" != "lost+found" ]
  then
    if [ -h "$i" ]
    then
      # Copy symlinks
      ln -s `readlink "$i"` "$i"
    elif [ -d "/$i" ]
    then
      # Bind mount directories
      mkdir "$i" &&
      mount -n -o bind "/$i" "$i"
    fi
  fi
  if [ $? -ne 0 ]; then exit 1; fi
done
# Don't use system /tmp, use a tmp in workspace.img.
umount tmp
mount -n -t devpts /dev/pts dev/pts
--------------------

With that, the hostfs might as well be read-only.

And as you can see, the above will very much NOT work with anything that cares 
about ROOT_DEV, since ROOT_DEV gets chrooted away fairly quickly... 

> > Also, I'd like to know whether there's a correct way to implement this
> > (using something different than root_dev, for instance the init[1] root
> > directory mount device). I understand that with the possibility for
> > multiple mounts the "root device" is more difficult to know (and maybe
> > this is the reason for which ROOT_DEV is bogus, is this?), but at least a
> > check on the param "rootfstype=hostfs" could be done.
>
> personally I think it's a bad misfeature by itself.  If you absolutely
> want it make it a mount option so it's explicit at least.

If it's going to have it at all, then yes it should be done the way.  Lots of 
filesystems have something close to this (The affs uid= and gid= options 
aren't that far off, for example.)

I'd like to point out that hostfs's rootflags= parsing needs an update.  Right 
now, it sets the path to the parent directory hostfs is to mount from, 
period.  (If omitted, the default is "rootflags=/".)  Appending something 
like ,rw gets treated as part of the path, so right now turning this feature 
on would require a remount after UML came up.

Unless it's ALWAYS the default that a hostfs mount turns files belonging to 
the user running UML into files belonging to root.  It's possible that this 
is really the intended behavior, by the way.  Whether the mount point is 
ROOT_DEV or not is probably irrelevant.

Then again, I haven't personally needed this behavior yet.  Mounting hostfs 
when UML is run by a non-root user means I can't mknod or chown, no matter 
what ownership or permissions the directory I'm in has.  And THAT is 
something that means I have to supplement hostfs with a loopback mount to get 
real writeable space in which I can get anything major done.  Making files 
look like they belong to root is a purely cosmetic change under those 
circumstances.

> And yes, the only place where ROOT_DEV makes sense is in the early boot
> process where the first filesystem in the first namespace is mounted,
> that's why I want to get rid of the export to modules for it.
>
> > Ok, this is nice. I'll repost the (updated) patch CC'ing Ingo Molnar
> > (unless there's another Ingo).
>
> Yupp, mingo

Is anyone, anywhere, actually USING this?  I'm using hostfs root fairly 
extensively and _not_ using the funky ownership rewriting feature.  Is this 
something people thought might be needed, or is somewhere somewhere actually 
inconvenienced by the lack?

Rob

      reply	other threads:[~2005-04-01  5:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22 16:21 [patch 03/12] uml: export getgid for hostfs blaisorblade
2005-03-22 18:11 ` Christoph Hellwig
2005-03-24  2:02   ` Blaisorblade
2005-03-29 11:45     ` Christoph Hellwig
2005-03-30 18:05       ` [uml-devel] " Blaisorblade
2005-03-31 14:40         ` Christoph Hellwig
2005-04-01  4:24           ` Rob Landley [this message]

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=200503312324.41299.rob@landley.net \
    --to=rob@landley.net \
    --cc=akpm@osdl.org \
    --cc=blaisorblade@yahoo.it \
    --cc=hch@infradead.org \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --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