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