search for: cap_sys_rawio

Il 22/08/2013 09:46, Timon Wang ha scritto: > Thanks Nicholas. > > I found that scsicmd can't pass all the scsi3_test but the result of > sg_inq is the same as it in the host. > > I am absolutely confused about this situation. Am I missed some > information about it? I am also confused. You need to understand the limitations that the clustering software is putting.

...by the lack of capability. Please check if enough capability was added to kvm process by the following steps. 1. Check the pid of kvm process. # ps -C qemu-system-x86_64 -o pid= 5177 2. Check the capability for the process. # getpcaps 5177 Capabilities for `5177': = cap_sys_rawio+i In my fedora19 environment, as seen in above, only cap_sys_rawio+i was added with rawio='yes'. Even though, cap_sys_rawio+ep is required to pass-through SCSI Reservation from the guest. Note that I succeeded to pass-through SCSI Reservation with the following steps in my environment,...

..., Jul 14, 2011 at 4:39 PM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote: >>> for stuff I probably should be disabling considering my goal of making >>> it difficult for root to compromise a system. ?And yes, modules are >>> disabled :) >> >> If you have CAP_SYS_RAWIO and some of the other interfaces you only think >> it is - the kiddies toolkits already include out of the box direct module >> loading hacks (in fact its fairly easy if you've got GPU PCI access to >> just put the module into video memory so that only the patching needs to &g...

...t;disk type='block' device='disk'> > > I'm not sure this will be enough, but if you want passthrough to the > host device you should use device='lun' here. However, you still would > not be able to issue SCSI reservations unless you run QEMU with the > CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). > After change the libvirt xml like this: <disk type='block' device='lun' rawio='yes'> <driver name='qemu' type='raw' cache='none'/> <source dev='/...

...disk'> >>> >>> I'm not sure this will be enough, but if you want passthrough to the >>> host device you should use device='lun' here. However, you still would >>> not be able to issue SCSI reservations unless you run QEMU with the >>> CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). >>> >> >> After change the libvirt xml like this: >> <disk type='block' device='lun' rawio='yes'> >> <driver name='qemu' type='raw' cache='...

...ck' device='disk'> >> >> I'm not sure this will be enough, but if you want passthrough to the >> host device you should use device='lun' here. However, you still would >> not be able to issue SCSI reservations unless you run QEMU with the >> CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). >> > > After change the libvirt xml like this: > <disk type='block' device='lun' rawio='yes'> > <driver name='qemu' type='raw' cache='none'/> &gt...

...lt;/disk> > <disk type='block' device='disk'> I'm not sure this will be enough, but if you want passthrough to the host device you should use device='lun' here. However, you still would not be able to issue SCSI reservations unless you run QEMU with the CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). Most important, it still would be unsafe to do this if the same device is passed to multiple virtual machines on the same host. You need to have NPIV and create separate virtual HBAs. Then each virtual machine should get a sepa...

...t;>> >>>> I'm not sure this will be enough, but if you want passthrough to the >>>> host device you should use device='lun' here. However, you still would >>>> not be able to issue SCSI reservations unless you run QEMU with the >>>> CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). >>>> >>> >>> After change the libvirt xml like this: >>> <disk type='block' device='lun' rawio='yes'> >>> <driver name='qemu' type='...

...gt;>>> I'm not sure this will be enough, but if you want passthrough to the >>>>> host device you should use device='lun' here. However, you still would >>>>> not be able to issue SCSI reservations unless you run QEMU with the >>>>> CAP_SYS_RAWIO capability (using "<disk ... rawio='yes'>"). >>>>> >>>> >>>> After change the libvirt xml like this: >>>> <disk type='block' device='lun' rawio='yes'> >>>> <driver name='...

My domain xml is like this: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>2008-2</name> <uuid>6325d8a5-468d-42e9-b5cb-9a04f5f34e80</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu

...========================================================== --- head-2007-02-27.orig/drivers/xen/char/mem.c 2007-03-05 10:00:18.000000000 +0100 +++ head-2007-02-27/drivers/xen/char/mem.c 2007-02-27 16:27:37.000000000 +0100 @@ -194,7 +194,7 @@ static int open_mem(struct inode * inode return capable(CAP_SYS_RAWIO) ? 0 : -EPERM; } -struct file_operations mem_fops = { +const struct file_operations mem_fops = { .llseek = memory_lseek, .read = read_mem, .write = write_mem, Index: head-2007-02-27/drivers/xen/evtchn/evtchn.c =================================================================== --- head-...

...SETGID), + MAKE_CAP(CAP_SETUID), + MAKE_CAP(CAP_SETPCAP), + MAKE_CAP(CAP_LINUX_IMMUTABLE), + MAKE_CAP(CAP_NET_BIND_SERVICE), + MAKE_CAP(CAP_NET_BROADCAST), + MAKE_CAP(CAP_NET_ADMIN), + MAKE_CAP(CAP_NET_RAW), + MAKE_CAP(CAP_IPC_LOCK), + MAKE_CAP(CAP_IPC_OWNER), + MAKE_CAP(CAP_SYS_MODULE), + MAKE_CAP(CAP_SYS_RAWIO), + MAKE_CAP(CAP_SYS_CHROOT), + MAKE_CAP(CAP_SYS_PTRACE), + MAKE_CAP(CAP_SYS_PACCT), + MAKE_CAP(CAP_SYS_ADMIN), + MAKE_CAP(CAP_SYS_BOOT), + MAKE_CAP(CAP_SYS_NICE), + MAKE_CAP(CAP_SYS_RESOURCE), + MAKE_CAP(CAP_SYS_TIME), + MAKE_CAP(CAP_SYS_TTY_CONFIG), + MAKE_CAP(CAP_MKNOD), + MAKE_CAP(CAP_LEASE), +...

.../writes in a format that can be parsed by envytools demsm tool. If enabled, register @@ -33,7 +32,6 @@ config DRM_MSM_REGISTER_LOGGING config DRM_MSM_GPU_SUDO bool "Enable SUDO flag on submits" depends on DRM_MSM && EXPERT - default n help Enable userspace that has CAP_SYS_RAWIO to submit GPU commands that are run from RB instead of IB1. This essentially gives Index: b/drivers/gpu/drm/nouveau/Kconfig =================================================================== --- a/drivers/gpu/drm/nouveau/Kconfig 2019-04-12 11:42:30.070095359 +0200 +++ b/drivers/gpu/drm/nouvea...

...parsed by envytools demsm tool. If enabled, register > @@ -33,7 +32,6 @@ config DRM_MSM_REGISTER_LOGGING > config DRM_MSM_GPU_SUDO > bool "Enable SUDO flag on submits" > depends on DRM_MSM && EXPERT > - default n > help > Enable userspace that has CAP_SYS_RAWIO to submit GPU commands > that are run from RB instead of IB1. This essentially gives > Index: b/drivers/gpu/drm/nouveau/Kconfig > =================================================================== > --- a/drivers/gpu/drm/nouveau/Kconfig 2019-04-12 11:42:30.070095359 +0200 > +++...

Some time ago i already tried to get running a Digital Oszilloscope DSO-2100 at the parallel port LPT1. But i give up to get it running. Now i have another problem (http://forum.winehq.org/viewtopic.php?p=38741#38741) and so i have tested this again. This time i added the keys to the registry for direct parport access: Code: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Wine\VDM]

This patchset applies to klibc mainline. As is it will probably collide with Maximilian's recent patch to rename run-init to switch_root posted last week. To boot an untrusted environment with certain capabilities locked out, we'd like to be able to drop the capabilities up front from early userspace, before we actually transition onto the root volume. This patchset implements this by