Description of problem: SELinux is preventing tpvmlp "read write" access on LCK..ttyS0 Version-Release number of selected component (if applicable): selinux-policy-3.7.19-2.fc13 How reproducible: Always upon boot/reboot Steps to Reproduce: 1. Power on or reboot system 2. Login with selinux enabled Actual results: 111 errors reference "tpvmlp" access denial Expected results: No error messages; vmware-tools ("tpvmlp) granted proper access Detailed Description & Additional Information: SELinux denied access requested by tpvmlp. It is not expected that this access is required by tpvmlp and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Additional Information: Source Context system_u:system_r:cupsd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lock_t:s0 Target Objects LCK..ttyS0 [ file ] Source tpvmgp Source Path /usr/lib/vmware-tools/bin32/vmware-tpvmlp Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.7.19-2.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.34-0.38.rc5.git0.fc14.i686.PAE #1 SMP Tue Apr 20 01:57:19 UTC 2010 i686 i686 Alert Count 112 First Seen Sun 25 Apr 2010 08:37:12 AM EDT Last Seen Sun 25 Apr 2010 08:37:18 AM EDT Local ID d7e29dcb-8dbc-4559-96ae-5a948f87fbd8 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1272199038.507:129): avc: denied { read write } for pid=2709 comm="tpvmlp" name="LCK..ttyS0" dev=dm-0 ino=130891 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=file Same bug has been reported previously in Bug 488591 with reference to FC 10.
Does this actually causing anything to break. It looks like a leaked file descriptor.
(In reply to comment #1) > Does this actually causing anything to break. It looks like a leaked file > descriptor. Not really; as far as system functionality is concerned...112 security alerts will pop up at random times when the system is running...though I do need to test whether "printing" capability is affected both locally and remote. I did read the exchange referenced in Bug 488591 and realize that this is a Vmware problem; but have not found that the Vmware folks have provided a solution.
You can add a dontaudit policy to stop these avc's from happening # grep tpvmlp /var/log/audit/audit.log | audit2allow -D -M mycups # semodule -i mycups.pp
(In reply to comment #3) > You can add a dontaudit policy to stop these avc's from happening > > # grep tpvmlp /var/log/audit/audit.log | audit2allow -D -M mycups > # semodule -i mycups.pp Roger...will do; thanks for the assist. Will keep fiddling with the vmware side of things to see if I can figure out a solution/work around.