qemu discuss - Feb 2007 - Using setfacl to control access to /dev/kqemu

Solaris 10U3, latest kqemu, qemu-0.9.0-CVS plus TAP patch.

I''m aware that a fair amount of "rootish" access is required
for the TAP and bridge
stuff, and I''m working on that.  As kind of a secuirty thought, I
figured
I''d use setfacl to give myself access to the /dev/kqemu device instead
of leaving it mode 664 or 666.

However, that didn''t work.  "getfacl /dev/kqemu"
output''s this:

# file: /dev/kqemu
# owner: root
# group: root
user::rw-
user:bent:rwx           #effective:rw-
group::rw-                #effective:rw-
mask:rw-
other:r--

However, running qemu with kqemu enabled shows me the message that
kqemu acceleration is not enabled.  Hmmm.  Change to 664, it works. Argh.

This kind of hackery worked when I wanted to get read access to my real 
/dev/dsk/c0d0p0 so I could use DamnSmallLinux to read my NTFS XP partition.

Ideas?
--
This message posted from opensolaris.org

> Solaris 10U3, latest kqemu, qemu-0.9.0-CVS plus TAP patch.
> 
> I''m aware that a fair amount of "rootish" access is
required for the TAP and
bridge
> stuff, and I''m working on that.  As kind of a secuirty thought, I
figured
> I''d use setfacl to give myself access to the /dev/kqemu device
instead
> of leaving it mode 664 or 666.
> 
> However, that didn''t work.  "getfacl /dev/kqemu"
output''s this:
> 
> # file: /dev/kqemu
> # owner: root
> # group: root
> user::rw-
> user:bent:rwx           #effective:rw-
> group::rw-                #effective:rw-
> mask:rw-
> other:r--
Works for me, on Nevada/snv_55b.

% getfacl /dev/kqemu 

# file: /dev/kqemu
# owner: root
# group: root
user::rw-
user:jk:rwx             #effective:rw-
group::r--              #effective:r--
mask:rw-
other:r--

% id
uid=109(jk) gid=20(usr)

% truss -s\!ALRM -t open /opt/SUNWqemu/bin/64/qemu-system-x86_64 -m 32 -fda 
/files/tiger2/tmp/winme_floppy.img
...
open("/dev/kqemu", O_RDWR)                      = 8
...

% ls -l /dev/kqemu
crw-r--r--+  1 root     root     208,  0 Okt 27 11:31 /dev/kqemu

> However, running qemu with kqemu enabled shows me the message that
> kqemu acceleration is not enabled.  Hmmm.  Change to 664, it works. Argh.
Why does 664 work?  Are you ("bent"?) a member of group
"root"?

> This kind of hackery worked when I wanted to get read access to my real 
> /dev/dsk/c0d0p0 so I could use DamnSmallLinux to read my NTFS XP partition.

> 
> 
> > Solaris 10U3, latest kqemu, qemu-0.9.0-CVS plus TAP
> patch.
> > 
> > I''m aware that a fair amount of "rootish" access is
> required for the TAP and  bridge
> > stuff, and I''m working on that.  As kind of a
> secuirty thought, I figured
> > I''d use setfacl to give myself access to the
> /dev/kqemu device instead
> > of leaving it mode 664 or 666.
> > 
> > However, that didn''t work.  "getfacl /dev/kqemu"
> output''s this:
> > 
> > # file: /dev/kqemu
> > # owner: root
> > # group: root
> > user::rw-
> > user:bent:rwx           #effective:rw-
> > group::rw-                #effective:rw-
> > mask:rw-
> > other:r--
> 
> Works for me, on Nevada/snv_55b.
> 
> % getfacl /dev/kqemu 
> 
> # file: /dev/kqemu
> # owner: root
> # group: root
> user::rw-
> user:jk:rwx             #effective:rw-
> group::r--              #effective:r--
> mask:rw-
> other:r--
> 
> % id
> uid=109(jk) gid=20(usr)
> 
> % truss -s\!ALRM -t open
> /opt/SUNWqemu/bin/64/qemu-system-x86_64 -m 32 -fda 
> /files/tiger2/tmp/winme_floppy.img
> ...
> open("/dev/kqemu", O_RDWR)                      = 8
> ...
> 
> % ls -l /dev/kqemu
> crw-r--r--+  1 root     root     208,  0 Okt 27 11:31
> /dev/kqemu
Ok.  I may have to play with the mask.  I''m getting
an effective permission as "r--" which may explain
the breakage.

Yep.  Changed mask to rw- and it started working.
Thanks for the example. I figured it out in just
a couple of minutes.
> > However, running qemu with kqemu enabled shows me
> the message that
> > kqemu acceleration is not enabled.  Hmmm.  Change
> to 664, it works. Argh.
> 
> Why does 664 work?  Are you ("bent"?) a member of
> group "root"?
actually sysadmin, which may inherit root.  Glad I can
get rid of that.
--
This message posted from opensolaris.org

> > > However, that didn''t work.  "getfacl
/dev/kqemu" output''s this:
> > > 
> > > # file: /dev/kqemu
> > > # owner: root
> > > # group: root
> > > user::rw-
> > > user:bent:rwx           #effective:rw-
> > > group::rw-                #effective:rw-
> > > mask:rw-
> > > other:r--
> > 
> > Works for me, on Nevada/snv_55b.
> >
> Ok.  I may have to play with the mask.  I''m getting
> an effective permission as "r--" which may explain
> the breakage.
Huh?  Your initial getfacl output showed effective permission
as "rw-":

    user:bent:rwx           #effective:rw-


Maybe this wasn''t a permission problem, but a problem
with mixing 32-bit qemu with 64-bit kernel kqemu module?
--
This message posted from opensolaris.org

> > > > However, that didn''t work.  "getfacl
> /dev/kqemu" output''s this:
> > > > 
> > > > # file: /dev/kqemu
> > > > # owner: root
> > > > # group: root
> > > > user::rw-
> > > > user:bent:rwx           #effective:rw-
> > > > group::rw-                #effective:rw-
> > > > mask:rw-
> > > > other:r--
> > > 
> > > Works for me, on Nevada/snv_55b.
> > >
> > Ok.  I may have to play with the mask.  I''m
> getting
> > an effective permission as "r--" which may explain
> > the breakage.
> 
> Huh?  Your initial getfacl output showed effective
> permission
> as "rw-":
> 
>     user:bent:rwx           #effective:rw-
> Maybe this wasn''t a permission problem, but a
> problem
> with mixing 32-bit qemu with 64-bit kernel kqemu
> module?
Unlikely, I only have a 32-bit system.  Probably some sort
of user operator.  Plus I''ve probably deleted and readded
the device a couple of times between 1.0.3pre9, the
modified one you did and the one Martin uploaded.

Thanks.
--
This message posted from opensolaris.org