On Fri, 10/21 10:54, Stefan Hajnoczi wrote: > On Fri, Oct 21, 2016 at 08:11:47AM +0800, Fam Zheng wrote: > > On Thu, 10/20 10:21, Andy Grover wrote: > > > On 10/20/2016 07:30 AM, Fam Zheng wrote: > > > > On Thu, 10/20 15:08, Stefan Hajnoczi wrote: > > > > > If a corrupt image is able to execute arbitrary code in the qemu-tcmu > > > > > process, does /dev/uio0 or the tcmu shared memory interface allow get > > > > > root or kernel privileges? > > > > > > > > I haven't audited the code, but target_core_user.ko should contain the > > > > access to > > > > /dev/uioX and make sure there is no security risk regarding buggy or > > > > malicious > > > > handlers. Otherwise it's a bug that should be fixed. Andy can correct > > > > me if I'm > > > > wrong. > > > > > > Yes... well, TCMU ensures that a bad handler can't scribble to kernel > > > memory > > > outside the shared memory area. > > > > Thanks! > > > > > > > > UIO devices are basically a "device drivers in userspace" kind of API so > > > they require root to use. I seem to remember somebody mentioning ways this > > > might work for less-privileged handlers (fd-passing??) but no way to do > > > this > > > exists just yet. > > > > In my example in the cover letter I use chmod + non-root which seems to be > > working properly. So I think fd-passing is a promising mechanism. > > Is there any way to use the in-kernel SCSI target without root? > > For example, if an unprivileged user wants to run an iSCSI target on an > unprivileged port to serve up a regular file (test.img).
No, not possible even on an unprivileged port AFAICT. Accessing targetcli requires root. > > If the answer is no then it's unlikely qemu-tcmu can ever be used > without root anyway... So you are right.. One possibility is we can implement some helper functionalities in a daemon (such as tcmu-runner, or a new one), to which an unprivileged qemu-tcmu then communicates this "export this LUN at XXX" requests with a DBus call, similar to how libtcmu registers the new handler on behalf of the program. Fam
