Re: [uml-devel] Hostfs permission checks are all wonky.

[Rob Landley <rob@landley.net>]

On Tuesday 22 March 2005 02:19 pm, Blaisorblade wrote:
> On Sunday 20 March 2005 20:17, Rob Landley wrote:
> > If I open a device like /dev/loop0 or /dev/console from a hostfs mount,
> > I'll get the UML device, not the host device, right?
>
> Obviously right.
>
> > So why are the permissions checks on hostfs devices done relative to the
> > _host_ user?
>
> What is the result from ls -l <that device>? Does it look readable for
> root?

Yes.

sh-2.05b# ls -l /dev/loop0
brw-rw----    1 root     disk       7,   0 Sep 15  2003 /dev/loop0
sh-2.05b#

A side effect of this is that I have to chown console to belong to the user 
running UML in order to run "./linux rootfstype=hostfs rw init=/bin/sh", 
because otherwise it can't open /dev/console to get the initial console.  
(This is with the stdio console.)  /dev/console has permissions 600.

> I'm not sure, however you could try the attached patch (there is also some
> whitespace cleanup, sorry), and if that does not work, then again I've not
> understood your scenario and you might answer the other questions in the
> email (I've first wrote the generic questions, then understood what is
> probably going on).
>
> Ok, I'm now seeing that UML uses access() (inside access_file()) to check
> permissions.
>
> See hostfs_permission -> access_file -> access. hostfs_permission (not
> access_file) should skip the "access_file" call in case its type is
> OS_TYPE_CHARDEV / OS_TYPE_BLOCKDEV / OS_TYPE_FIFO / OS_TYPE_SOCK.
>
> Look at init_inode() about how to see the file's type, but even better look
> at the cached information, i.e. inode->i_mode and the S_* access macro
> (look at init_special_inode about this).

Yeah, that'd do it.

I might not get to this tonight, but I'll try the patch tomorrow at the 
latest.

> > If /dev/console doesn't belong to the current user, the
> > system can't even open the initial console, despite the fact the output
> > does NOT go to TTY1 if I'm running it an xterm.
>
> /dev/console and /dev/tty1 are entirely different. If you open a getty
> on /dev/console, Ctrl-C won't work there.

I'm booting with init=/bin/sh (or a shellscript).  It opens /dev/console for 
me behind the scenes, I don't make any special arrangements.  You're right, 
ctrl-c doesn't work.  It would be nice if it did...

What I meant by not going to /dev/tty1 is that's where console output goes by 
default in the parent system, so if the thing were managing to write to the 
parent's /dev/console that's where all the output would wind up.  But it's 
not, it's going to stdout like it's supposed to.  Minus the wonky permissions 
check you noticed above...

> 1) Which version of UML are you using? If you are using the incrementals,
> they contain the hostfs rewrite which has all these problems... (with that,
> you can't even do a stat on a device you don't own, wrongly).

2.6.11 from kernel.org.

> 2) Which command line? I recall you run with hostfs as root fs, but I'm not
> really sure of this.

Try it, it's easy.

./linux rootfstype=hostfs rootflags=/ rw init=/bin/sh

If you run it from an xterm, that should work.  If you run it from an ssh 
session, it probably won't because of the permissions on /dev/console 
discussed above.

> 3) When you have hostfs as your root fs, there is some special code to
> handle this which may be reconsidered. I.e., when you have a file on the
> host owned by the user running UML, that is seen as owned by root inside
> UML. Actually it's not related to your current problem, but if ever you
> notice any bugs, please let us know.

You mean like this darn bug I've been seeing for weeks?

io scheduler noop registered
loop: loaded (max 8 devices)
Initialized stdio console driver
Console initialized on /dev/tty0
VFS: Mounted root (hostfs filesystem).
idr_remove called for id=3 which is not allocated.
Call Trace:
a01fba48:  [<a007cbec>]
a01fba84:  [<a007cc13>]
a01fba9c:  [<a0085eaa>]
a01fbb04:  [<a0085697>]
a01fbb4c:  [<a00860a4>]
a01fbb68:  [<a007d09d>]
a01fbb74:  [<a004cc5e>]
a01fbb7c:  [<a004cdb6>]
a01fbb80:  [<a008e193>]
a01fbba8:  [<a004cd31>]
a01fbbc8:  [<a004526c>]
a01fbbe4:  [<a00451bf>]
a01fbc24:  [<a0045365>]
a01fbc38:  [<a0045445>]
a01fbc54:  [<a0011de9>]
a01fbcc0:  [<a0011e30>]
a01fbce4:  [<a0012d18>]
a01fbd14:  [<a0017887>]
a01fbd20:  [<a0097808>]

sh-2.05b#

It does that all the time.  (The id=? bit changes with each run.)  Somewhere 
around here I've got a trace from when I built it with debug symbols, I can 
get that for you at the same time I try out your patch...

> > Similarly, if /dev/loop0 is chmod 600 and I run UML as a normal user and
> > try to do a mount -o loop, it says it can't find a loop device.
> >
> > Yet if I
> > run UML as root, it doesn't allocate one of the parent's loop devices,
> > UML does it internally...
> >
> > I'm told there's a major rewrite of hostfs underway.  Is it worth me
> > trying to patch the existing hostfs code, or should I go try to track
> > down the new stuff and try it out?
>
> Well, the "rewrite" (currently in the incrementals) is waiting for more
> urgent work since a lot of time (it was started by the 2.4.24-2um release),
> and it has a lot of problems right now. We are going to keep the old hostfs
> available for a lot...
>
> So you'd better go debugging the current code, IMHO (and even simply
> testing the patch); we will subsequently port those changes to the new
> code.

Cool.  Will do...

Rob


-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel