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

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

[Rob Landley]

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?

So why are the permissions checks on hostfs devices done relative to the 
_host_ user?  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.

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?

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&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

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

[Blaisorblade]

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

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?

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).

> 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.

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) Which command line? I recall you run with hostfs as root fs, but I'm not 
really sure of this.
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.

> 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.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

[-- Attachment #2: uml-fix-hostfs-special-perm-handling.patch --]
[-- Type: text/x-diff, Size: 1788 bytes --]


From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
CC: Rob Landley <rob@landley.net>
When opening devices nodes on hostfs, it does not make sense to call
access(), since we are not going to open the file on the host.

If the device node is owned by root, the root user in UML should succeed in
opening it, even if UML won't be able to open the file.

As reported by Rob Landley, UML currently does not follow this, so here's an
(untested) fix.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 linux-2.6.11-paolo/fs/hostfs/hostfs_kern.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff -puN fs/hostfs/hostfs_kern.c~uml-fix-hostfs-special-perm-handling fs/hostfs/hostfs_kern.c
--- linux-2.6.11/fs/hostfs/hostfs_kern.c~uml-fix-hostfs-special-perm-handling	2005-03-22 20:10:07.000000000 +0100
+++ linux-2.6.11-paolo/fs/hostfs/hostfs_kern.c	2005-03-22 20:12:45.000000000 +0100
@@ -806,15 +806,21 @@ int hostfs_permission(struct inode *ino,
 	char *name;
 	int r = 0, w = 0, x = 0, err;
 
-	if(desired & MAY_READ) r = 1;
-	if(desired & MAY_WRITE) w = 1;
-	if(desired & MAY_EXEC) x = 1;
+	if (desired & MAY_READ) r = 1;
+	if (desired & MAY_WRITE) w = 1;
+	if (desired & MAY_EXEC) x = 1;
 	name = inode_name(ino, 0);
-	if(name == NULL) return(-ENOMEM);
-	err = access_file(name, r, w, x);
+	if (name == NULL) return(-ENOMEM);
+
+	if (S_ISCHR(ino->i_mode) || S_ISBLK(ino->i_mode) ||
+			S_ISFIFO(ino->i_mode) || S_ISSOCK(ino->i_mode))
+		err = 0;
+	else
+		err = access_file(name, r, w, x);
 	kfree(name);
-	if(!err) err = generic_permission(ino, desired, NULL);
-	return(err);
+	if(!err)
+		err = generic_permission(ino, desired, NULL);
+	return err;
 }
 
 int hostfs_setattr(struct dentry *dentry, struct iattr *attr)
_

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

[Rob Landley]

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

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

[Rob Landley]

On Tuesday 22 March 2005 02:19 pm, Blaisorblade wrote:

> 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).

Just confirming: this patch fixed it.  Both /dev/loop0 and /dev/console work 
just fine with hostfs root now.

Can this patch make it into 2.6.12?

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

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

[Blaisorblade]

On Wednesday 23 March 2005 09:13, Rob Landley wrote:
> On Tuesday 22 March 2005 02:19 pm, Blaisorblade wrote:
> > 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).
>
> Just confirming: this patch fixed it.  Both /dev/loop0 and /dev/console
> work just fine with hostfs root now.
>
> Can this patch make it into 2.6.12?
Yes, it's on his way (in next group of merges however).
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&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

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

[Blaisorblade]

On Wednesday 23 March 2005 07:09, Rob Landley wrote:
> On Tuesday 22 March 2005 02:19 pm, Blaisorblade wrote:
> > On Sunday 20 March 2005 20:17, Rob Landley wrote:


> 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.
>

> > > 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.
I'm not understanding the difference at the moment...

> 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...
I'd like that a lot, and also your .config - I've never seen that message nor 
I know the users of that kernel internal API (but probably UML itself isn't 
using that).

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&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

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

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Thursday 24 March 2005 05:53 am, Blaisorblade wrote:

> > 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.
>
> I'm not understanding the difference at the moment...

I just meant that startx (which is root) chmods /dev/console to belong to the 
user who ran X11.  Under a normal text console, /dev/console belongs to root.  
(So sometimes it would refuse to run and sometimes it wouldn't, and it took a 
little while to figure out what was wrong.)

This is not a problem with your patch applied.

> > 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...
>
> I'd like that a lot, and also your .config - I've never seen that message
> nor I know the users of that kernel internal API (but probably UML itself
> isn't using that).

Well, here's the .config, anyway.  I don't know where the debug trace is at 
the moment, so I'll recompile with debug symbols to try to replicate with 
debug info now.  (It happens a LOT for me, on several different machines.  
Possibly related to using hostfs as root... :)

Rob

[-- Attachment #2: linux-config-um --]
[-- Type: text/plain, Size: 4250 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc4
# Sat Feb 19 14:32:29 2005
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_USERMODE=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y

#
# UML-specific options
#
CONFIG_MODE_TT=y
CONFIG_MODE_SKAS=y
# CONFIG_64_BIT is not set
CONFIG_TOP_ADDR=0xc0000000
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
CONFIG_LD_SCRIPT_STATIC=y
# CONFIG_NET is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_HOSTFS=y
# CONFIG_MCONSOLE is not set
# CONFIG_HOST_2G_2G is not set
CONFIG_NEST_LEVEL=0
CONFIG_KERNEL_HALF_GIGS=1
CONFIG_KERNEL_STACK_ORDER=2
# CONFIG_UML_REAL_TIME_CLOCK is not set

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_SYSCTL is not set
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_SHMEM is not set
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_TINY_SHMEM=y

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set

#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
# CONFIG_SSL is not set
# CONFIG_NULL_CHAN is not set
# CONFIG_PORT_CHAN is not set
# CONFIG_PTY_CHAN is not set
# CONFIG_TTY_CHAN is not set
# CONFIG_XTERM_CHAN is not set
CONFIG_NOCONFIG_CHAN=y
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pty"
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_WATCHDOG is not set
# CONFIG_UML_SOUND is not set
# CONFIG_SOUND is not set
# CONFIG_HOSTAUDIO is not set

#
# Block devices
#
# CONFIG_BLK_DEV_UBD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
CONFIG_LBD=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_NETDEVICES is not set

#
# Networking support
#
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
# CONFIG_SYSFS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_SQUASHFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_INPUT is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set

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

[Rob Landley]

On Thursday 24 March 2005 05:53 am, Blaisorblade wrote:
> > 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...
>
> I'd like that a lot, and also your .config - I've never seen that message
> nor I know the users of that kernel internal API (but probably UML itself
> isn't using that).

VFS: Mounted root (hostfs filesystem).
idr_remove called for id=1 which is not allocated.
Call Trace:
a086fa1c:  [<a00784c2>] sub_remove+0xe0/0xe9
a086fa58:  [<a00784ea>] idr_remove+0x1f/0x8b
a086fa74:  [<a007f1d0>] release_dev+0x64f/0x665
a086fae0:  [<a007e918>] init_dev+0x37e/0x472
a086fb28:  [<a007f3b7>] tty_open+0x1d1/0x300
a086fb38:  [<a00789cb>] kobject_get+0x14/0x1c
a086fb48:  [<a004d6bb>] cdev_get+0xb/0xe
a086fb54:  [<a004d830>] exact_lock+0xb/0x17
a086fb5c:  [<a0087911>] kobj_lookup+0x90/0xba
a086fb6c:  [<a004d81d>] exact_match+0x0/0x8
a086fb88:  [<a004d79c>] chrdev_open+0xcb/0xe8
a086fbac:  [<a0045b77>] dentry_open+0xa7/0x151
a086fbcc:  [<a0045acb>] filp_open+0x40/0x45
a086fc0c:  [<a0045c76>] get_unused_fd+0x55/0x9d
a086fc24:  [<a0045d5e>] sys_open+0x32/0x6c
a086fc44:  [<a0011f57>] execute_syscall_tt+0xd3/0xe0
a086fcb4:  [<a0011fa2>] syscall_handler_tt+0x3e/0x66
a086fcdc:  [<a0012e8f>] sig_handler_common_tt+0x93/0xe4
a086fd10:  [<a0017a48>] sig_handler+0x18/0x27
a086fd20:  [<a0091728>] __restore+0x0/0x8

sh-2.05b#

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&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

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

[Rob Landley]

On Friday 29 April 2005 04:53 pm, Blaisorblade wrote:
> While doing other stuff, I've understood how UML reaches that code:
>
> hostfs_read_sb->get_sb_nodev->set_anon_super()->idr_XXX. However, I can't
> understand why the hell UML could have bugs in this path. Probably running
> it with a root hostfs will trigger this, but for now I haven't the time to
> play with this.

I have a vague recollection that running UML not just with a root hostfs but 
as the root user on the host made the problem more likely to occur.  (Don't 
know if that's actually necessary to reproduce or not, and don't have free 
space on my laptop to compile up a copy just now...)

> Also, I've seen somebody else with a "idr" problem, related to devpts
> (recent posts, titled "ssh again" IIRC). Still I don't understand what's
> going on.

Rob


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Blaisorblade]

On Monday 28 March 2005 21:48, Rob Landley wrote:
> On Thursday 24 March 2005 05:53 am, Blaisorblade wrote:
> > > 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...
> >
> > I'd like that a lot, and also your .config - I've never seen that message
> > nor I know the users of that kernel internal API (but probably UML itself
> > isn't using that).
>
> VFS: Mounted root (hostfs filesystem).
> idr_remove called for id=1 which is not allocated.
> Call Trace:
> a086fa1c:  [<a00784c2>] sub_remove+0xe0/0xe9
> a086fa58:  [<a00784ea>] idr_remove+0x1f/0x8b
> a086fa74:  [<a007f1d0>] release_dev+0x64f/0x665
> a086fae0:  [<a007e918>] init_dev+0x37e/0x472
> a086fb28:  [<a007f3b7>] tty_open+0x1d1/0x300
> a086fb38:  [<a00789cb>] kobject_get+0x14/0x1c
> a086fb48:  [<a004d6bb>] cdev_get+0xb/0xe
> a086fb54:  [<a004d830>] exact_lock+0xb/0x17
> a086fb5c:  [<a0087911>] kobj_lookup+0x90/0xba
> a086fb6c:  [<a004d81d>] exact_match+0x0/0x8
> a086fb88:  [<a004d79c>] chrdev_open+0xcb/0xe8
> a086fbac:  [<a0045b77>] dentry_open+0xa7/0x151
> a086fbcc:  [<a0045acb>] filp_open+0x40/0x45
> a086fc0c:  [<a0045c76>] get_unused_fd+0x55/0x9d
> a086fc24:  [<a0045d5e>] sys_open+0x32/0x6c
> a086fc44:  [<a0011f57>] execute_syscall_tt+0xd3/0xe0
> a086fcb4:  [<a0011fa2>] syscall_handler_tt+0x3e/0x66
> a086fcdc:  [<a0012e8f>] sig_handler_common_tt+0x93/0xe4
> a086fd10:  [<a0017a48>] sig_handler+0x18/0x27
> a086fd20:  [<a0091728>] __restore+0x0/0x8
While doing other stuff, I've understood how UML reaches that code:

hostfs_read_sb->get_sb_nodev->set_anon_super()->idr_XXX. However, I can't 
understand why the hell UML could have bugs in this path. Probably running it 
with a root hostfs will trigger this, but for now I haven't the time to play 
with this.

Also, I've seen somebody else with a "idr" problem, related to devpts (recent 
posts, titled "ssh again" IIRC). Still I don't understand what's going on.
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade





-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel