Bug 798758 - Can't start virtual machine when selinux is in enforce mode
Summary: Can't start virtual machine when selinux is in enforce mode
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
: 798746 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-29 18:50 UTC by Arnold Wang
Modified: 2012-03-08 17:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-06 09:34:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Arnold Wang 2012-02-29 18:50:13 UTC
Description of problem:
When the selinux is in enforce mode, I can't start the guest machine. I manually relabel the file system and it didn't help. "audit2allow -alr" generates the following:
-bash-4.2# audit2allow -alr

require {
	type iscsid_t;
	type var_log_t;
	type svirt_t;
	class process execmem;
	class file open;
}

#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;

#============= svirt_t ==============
allow svirt_t self:process execmem;


The raw audit logs:
type=VIRT_MACHINE_ID msg=audit(1330541247.189:187): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 vm-ctx=system_u:system_r:svirt_t:s0:c759,c959 img-ctx=system_u:object_r:svirt_image_t:s0:c759,c959: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:188): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=deny vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=all: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:189): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=major category=pty maj=88 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:190): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/null rdev=01:03 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:191): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/full rdev=01:07 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:192): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/zero rdev=01:05 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:193): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/random rdev=01:08 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:194): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/urandom rdev=01:09 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:195): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/ptmx rdev=05:02 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.225:196): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/kvm rdev=? acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed'
type=VIRT_RESOURCE msg=audit(1330541247.225:197): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/kqemu rdev=? acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed'
type=VIRT_RESOURCE msg=audit(1330541247.226:198): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/rtc rdev=FE:00 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.226:199): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/hpet rdev=0A:E4 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=ANOM_PROMISCUOUS msg=audit(1330541247.250:200): dev=vnet0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
type=SYSCALL msg=audit(1330541247.250:200): arch=c000003e syscall=16 success=yes exit=0 a0=17 a1=89a2 a2=7f9d40274ca0 a3=7 items=0 ppid=1 pid=1170 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)
type=VIRT_RESOURCE msg=audit(1330541247.252:201): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=net reason=open vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 net='52:54:00:2C:7C:D2' path="/dev/net/tun" rdev=0A:C8: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1330541247.303:202): avc:  denied  { execmem } for  pid=30326 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c759,c959 tcontext=system_u:system_r:svirt_t:s0:c759,c959 tclass=process
type=SYSCALL msg=audit(1330541247.303:202): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=32000000 a2=7 a3=62 items=0 ppid=1 pid=30326 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=system_u:system_r:svirt_t:s0:c759,c959 key=(null)
type=ANOM_PROMISCUOUS msg=audit(1330541247.306:203): dev=vnet0 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295
type=VIRT_RESOURCE msg=audit(1330541247.432:204): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=disk reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-disk="?" new-disk="/var/lib/libvirt/images/Windows7.img": exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.432:205): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=net reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-net='?' new-net='52:54:00:2C:7C:D2': exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.432:206): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=mem reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-mem=0 new-mem=4194304: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1330541247.432:207): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=vcpu reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-vcpu=0 new-vcpu=1: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_CONTROL msg=audit(1330541247.432:208): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start reason=booted vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed'

BTW, I filed bug 798746 initially in libvirt group. I described the behaviour in more details there.  

Version-Release number of selected component (if applicable):
-bash-4.2# rpm -qa | grep selin
libselinux-python-2.1.6-6.fc16.x86_64
selinux-policy-targeted-3.10.0-75.fc16.noarch
libselinux-2.1.6-6.fc16.x86_64
libselinux-2.1.6-6.fc16.i686
libselinux-utils-2.1.6-6.fc16.x86_64
selinux-policy-3.10.0-75.fc16.noarch


How reproducible:
Start virtual machine manager, select the guest machine and run.

Steps to Reproduce:
1. Start the virtual machine manager
2. Select the guest machine need be started
3. Right click and select "run"

Actual results:
Received the above error messages.

Expected results:
The guest machine starts.

Additional info:

Comment 1 Daniel Walsh 2012-02-29 19:08:27 UTC
audit2allow -i /tmp/t


#============= svirt_t ==============
#!!!! This avc can be allowed using the boolean 'virt_use_execmem'

allow svirt_t self:process execmem;

You did not include the var_log_t avc.

But I think this is probably a mislabeled file.

Comment 2 Arnold Wang 2012-03-01 23:50:08 UTC
I just tried the following:
1. touch /.autorelabel; reboot
2. setsebool -P virt_use_execmem=true
and as far as I can tell, no difference made.

-bash-4.2# getsebool virt_use_execmem
virt_use_execmem --> on
-bash-4.2# audit2allow -alr

require {
	type iscsid_t;
	type var_log_t;
	type svirt_t;
	class process execmem;
	class file open;
}

#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;

#============= svirt_t ==============
allow svirt_t self:process execmem;

Comment 3 Miroslav Grepl 2012-03-02 08:29:31 UTC
#============= svirt_t ==============
allow svirt_t self:process execmem;

is allowed in the latest F17 policy. You will need to update.


#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;

What does

$ ls -Z /var/log/iscs*

Comment 4 Arnold Wang 2012-03-02 15:13:15 UTC
[awang@mars ~]$ ls -lZ /var/log/iscs*
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120212
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120221

Comment 5 Miroslav Grepl 2012-03-06 09:34:53 UTC
$ restorecon -R  -v /var/log/iscsiui*

Did you start iscsid by hand? I mean without using either service script or systemd unit file?

Comment 6 Arnold Wang 2012-03-06 18:23:57 UTC
No, I didn't start the iscsi manually. Besides, as you can see from my comments before, I have relabeled the file systems many times and didn't make any difference. 
Any way, I just did again. 
--- before ---
-bash-4.2# ls -lZ /var/log/iscsiui*
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120212
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120221
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120302
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120305

--- relabel them ---
-bash-4.2# restorecon -R  -v /var/log/iscsiui*

--- looks exactly as what they were ---
-bash-4.2# ls -lZ /var/log/iscsiui*
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120212
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120221
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120302
-rw-r--r--. root root system_u:object_r:var_log_t:s0   /var/log/iscsiuio.log-20120305
-bash-4.2# 
Since nothing changed in the labels, not sure how that can fix my problem. 

If iscsi logs files need special label, they're NOT defined in the policy shipped. 
-bash-4.2# grep -i iscsi /etc/selinux/targeted/contexts/files/file_contexts*
/etc/selinux/targeted/contexts/files/file_contexts:/var/lib/iscsi(/.*)?	system_u:object_r:iscsi_var_lib_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/var/lock/iscsi(/.*)?	system_u:object_r:iscsi_lock_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/sbin/iscsid	--	system_u:object_r:iscsid_exec_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/sbin/iscsiuio	--	system_u:object_r:iscsid_exec_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/sbin/brcm_iscsiuio	--	system_u:object_r:iscsid_exec_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/var/run/iscsid\.pid	--	system_u:object_r:iscsi_var_run_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/var/log/brcm-iscsi\.log	--	system_u:object_r:iscsi_log_t:s0

The defined one is for /var/log/brcm-iscsi\.log. 

I'm disappointed you closed this without even waiting for the result from the user. With a response like this, I don't know how you expect people will continue file bug report in the future.
Thanks.

Comment 7 Daniel Walsh 2012-03-06 18:57:53 UTC
I see the label in selinux-policy-3.10.0-77.fc16

Comment 8 Arnold Wang 2012-03-07 00:14:39 UTC
1. What's the label should be? I can verify the fix manually if you tell me what's the "correct" label should be? I tried "system_u:object_r:iscsi_log_t:s0" for /var/log/iscsi* and it didn't help. 
2. The latest "published" selinux-policy seems to me is still 3.10.0-75. I can wait for it be realised to try again.
Thanks.

Comment 9 Arnold Wang 2012-03-07 00:17:50 UTC
*** Bug 798746 has been marked as a duplicate of this bug. ***

Comment 10 Daniel Walsh 2012-03-07 19:34:04 UTC
Yes that is the label, what do you mean it does not work?

Comment 11 Arnold Wang 2012-03-08 00:09:30 UTC
Here is what I just tried. Please let me know if I did anything wrong.
-bash-4.2# chcon system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log*
-bash-4.2# ls -lZ /var/log/iscsiuio.log*
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120212
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120221
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120302
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120305

After that, I launched the guest machine and received the following alert:

SELinux is preventing /sbin/iscsiuio from open access on the file /var/log/iscsiuio.log.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that iscsiuio should be allowed open access on the iscsiuio.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep iscsiuio /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:iscsid_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                /var/log/iscsiuio.log [ file ]
Source                        iscsiuio
Source Path                   /sbin/iscsiuio
Port                          <Unknown>
Host                          mars.astro.net
Source RPM Packages           iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     mars.astro.net
Platform                      Linux mars.astro.net 3.2.9-1.fc16.x86_64 #1 SMP
                              Thu Mar 1 01:41:10 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    Wed 07 Mar 2012 03:45:29 PM PST
Last Seen                     Wed 07 Mar 2012 03:45:29 PM PST
Local ID                      2acb1cb2-1cfe-4157-a691-ff7d038d0c50

Raw Audit Messages
type=AVC msg=audit(1331163929.416:59): avc:  denied  { open } for  pid=1264 comm="iscsiuio" name="iscsiuio.log" dev=dm-6 ino=4308 scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file


type=SYSCALL msg=audit(1331163929.416:59): arch=x86_64 syscall=open success=yes exit=ESRCH a0=4203b0 a1=441 a2=1b6 a3=238 items=0 ppid=1263 pid=1264 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=iscsiuio exe=/sbin/iscsiuio subj=system_u:system_r:iscsid_t:s0 key=(null)

Hash: iscsiuio,iscsid_t,var_log_t,file,open

audit2allow

#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;

audit2allow -R

#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;

Comment 12 Arnold Wang 2012-03-08 00:27:35 UTC
Ok, I rebooted the machine and that "fixed" the problem. I always assumed these labels can be changed on the fly. 
Regarding the other earlier comment on 'virt_use_execmem', I want to make sure I understand its status correctly. 
Miroslav mentioned that 'virt_use_execmem' is only available in the latest F17 policy, howeve when I did 'getsebool -a', I found it. Of course, when I tried to enable it, it didn't make any difference. 
-bash-4.2# getsebool virt_use_execmem
virt_use_execmem --> on

Can someone explain it in more detail of this? If I'm going to stay with F16, do I have to build my own customized module so I can set the SELinux to enforce mode again?   
Thanks.

Comment 13 Miroslav Grepl 2012-03-08 09:28:37 UTC
'virt_use_execmem' is also in F16 but it had a different meaning which I fixed and now F16==F17 related to this boolean.

How do you start iscsid service?

Comment 14 Arnold Wang 2012-03-08 17:15:27 UTC
Thanks for the explanation. It makes senses now. 
1. I'm curious when I can expect to "receive" your fix via "yum update".
2. The iscsid service is started by the system. Since this is my home PC and I don't have iscsi devices around at all, there is no need for me to mess around the iscsid service at all. 
-bash-4.2# systemctl is-enabled iscsid.service
iscsid.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig iscsid --level=5
enabled
-bash-4.2#


Note You need to log in before you can comment on or make changes to this bug.