From: Rob L. <ro...@la...> - 2005-03-20 23:18:53
|
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 |
From: Blaisorblade <bla...@ya...> - 2005-03-22 19:42:52
Attachments:
uml-fix-hostfs-special-perm-handling.patch
|
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 |
From: Rob L. <ro...@la...> - 2005-03-23 09:16:13
|
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 |
From: Blaisorblade <bla...@ya...> - 2005-03-24 02:03:33
|
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 |
From: Rob L. <ro...@la...> - 2005-03-23 07:49:55
|
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 |
From: Blaisorblade <bla...@ya...> - 2005-03-24 10:54:42
|
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 |
From: Rob L. <ro...@la...> - 2005-03-28 18:26:12
Attachments:
linux-config-um
|
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 |
From: Rob L. <ro...@la...> - 2005-03-28 20:51:26
|
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 |
From: Blaisorblade <bla...@ya...> - 2005-04-28 20:52:40
|
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 |
From: Rob L. <ro...@la...> - 2005-04-29 00:48:38
|
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 |