That seems to be old historical code that's not even expected to work.  If you think there is value in making it work, you could send a fix.

Send a patch: https://lists.fedorahosted.org/archives/list/sanlock-devel@lists.fedorahosted.org/thread/633RRMJDIEEQYIRZ4RXBPYON7JPVOIGX/

Hi David, there is a selinux issue when running example.py with the patch in comment3.

First of all, I enabled all the selinux bool about sanlock
# getsebool -a|grep sanlock
sanlock_enable_home_dirs --> on
sanlock_use_fusefs --> on
sanlock_use_nfs --> on
sanlock_use_samba --> on
virt_use_sanlock --> on

When selinux is enforcing, run example.py:
# python example.py                   
Creating the sanlock disk
Registering to sanlock
Initializing 'lockspace1'
Traceback (most recent call last):
  File "example.py", line 70, in <module>
    main()
  File "example.py", line 32, in main
    sanlock.write_lockspace(LOCKSPACE_NAME, disk)
sanlock.SanlockException: (19, 'Sanlock lockspace write failure', 'No such device')


When selinux is permissive, it works:
# python example.py 
Creating the sanlock disk
Registering to sanlock
Initializing 'lockspace1'
Initializing 'resource1' on 'lockspace1'
Acquiring the id '1' on 'lockspace1'
Acquiring 'resource1' on 'lockspace1'
Trying to get lockspace 'lockspace1' hosts
Trying to get lockspace 'lockspace1' hosts
Lockspace 'lockspace1' hosts:  [{'generation': 1, 'host_id': 1, 'flags': 3, 'io_timeout': 10, 'timestamp': 3446}]
Resource 'resource1' owners:  [{'generation': 1, 'host_id': 1, 'flags': 0, 'io_timeout': 0, 'timestamp': 3467}]
Releasing 'resource1' on 'lockspace1'
Releasing the id '1' on 'lockspace1'
Removing the sanlock disk

And I got a selinux alert when running the script:
```
SELinux is preventing /usr/sbin/sanlock from open access on the file /tmp/tmpaaVIF6.

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

If you believe that sanlock should be allowed open access on the tmpaaVIF6 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:
# ausearch -c 'sanlock' --raw | audit2allow -M my-sanlock
# semodule -i my-sanlock.pp

Additional Information:
Source Context                system_u:system_r:sanlock_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                /tmp/tmpaaVIF6 [ file ]
Source                        sanlock
Source Path                   /usr/sbin/sanlock
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           sanlock-3.4.0-1.el7.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-144.el7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.10.0-656.el7.x86_64
                              #1 SMP Thu Apr 20 12:21:33 EDT 2017 x86_64 x86_64
Alert Count                   7
First Seen                    2017-04-24 18:19:39 CST
Last Seen                     2017-04-25 10:43:07 CST
Local ID                      427a3d8f-6519-44e8-8279-0f802d146dc1

Raw Audit Messages
type=AVC msg=audit(1493088187.248:498): avc:  denied  { open } for  pid=6818 comm="sanlock" path="/tmp/tmpaaVIF6" dev="dm-1" ino=134844239 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file


type=SYSCALL msg=audit(1493088187.248:498): arch=x86_64 syscall=open success=yes exit=ENOMEM a0=7fa82570c410 a1=105002 a2=0 a3=1 items=0 ppid=1 pid=6818 auid=4294967295 uid=179 gid=179 euid=179 suid=179 fsuid=179 egid=179 sgid=179 fsgid=179 tty=(none) ses=4294967295 comm=sanlock exe=/usr/sbin/sanlock subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null)

Hash: sanlock,sanlock_t,user_tmp_t,file,open
```

I think it is why example.py failed when selinux is enforcing.
I'm not sure if sanlock should have permission to open files in /tmp. And is it a selinux-policy bug? Or are there some considerations on security to prevent sanlock open tmp files?

It's just an example, and I don't understand why it's even useful to keep around. It's surely not worth any effort to make it work with selinux and /tmp.  If there's some hidden value in this example that I'm not aware of, please let me know and we'll move it somewhere else.

I think we can remove the example.py file. We have proper tests now, and this
example is hard to maintain and test.