Bug 730742

Summary:	quicktest.sh failures in libcap package
Product:	Red Hat Enterprise Linux 6	Reporter:	Miroslav Vadkerti <mvadkert>
Component:	libcap	Assignee:	Karsten Hopp <karsten>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.1	CC:	sgrubb
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-18 15:37:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Miroslav Vadkerti 2011-08-15 15:17:39 UTC

Description of problem:
Sanity quicktest comming with libcap is showing these problems with script capabilities:
-----------------------
Shell script got [ =ep] - you should upgrade your kernel
shell scripts can have capabilities (bug)

and shows these failures:
-------------------------
EXPECT FAILURE: TEST: ./capsh --secbits=32 --keep=1 --keep=0 --print
prctl(PR_SET_KEEPCAPS, 1) failed: Operation not permitted
FAILED

EXPECT FAILURE: TEST: ./capsh --secbits=47 -- -c ping -c1 localhost
ping: icmp open socket: Operation not permitted
FAILED

EXPECT FAILURE: TEST: ./capsh --secbits=47 --print -- -c /bin/ping -c1 localhost
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin
Securebits: 057/0x2f
 secure-noroot: yes (locked)
 secure-no-suid-fixup: yes (locked)
 secure-keep-caps: no (locked)
uid=0
ping: icmp open socket: Operation not permitted
FAILED

EXPECT FAILURE: TEST: ./capsh --drop=cap_net_raw,cap_chown --secbits=0x2f --print -- -c ./ping -c1 localhost
Current: =ep
Bounding set =cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin
Securebits: 057/0x2f
 secure-noroot: yes (locked)
 secure-no-suid-fixup: yes (locked)
 secure-keep-caps: no (locked)
uid=0
/bin/bash: ./ping: Operation not permitted
FAILED



Version-Release number of selected component (if applicable):
libcap-2.16-5.3.el6

How reproducible:
100%

Steps to Reproduce:
1. run progs/quicktests.sh
  
Actual results:
Errors

Expected results:
No errors

Additional info:
On Fedora there is only one failure is shown:
EXPECT FAILURE: TEST: ./capsh --secbits=32 --keep=1 --keep=0 --print
prctl(PR_SET_KEEPCAPS, 1) failed: Operation not permitted
FAILED

Comment 1 Miroslav Vadkerti 2011-08-15 15:21:56 UTC

The previous libcap si failing the same way so this is not a regression. The question that bothers me the most is why the quicktest is complaining about script capabilities. The ping related issue may be expected but I need a confirmation on this.

Comment 2 Miroslav Vadkerti 2011-08-17 14:59:16 UTC

Update after discussion with sgrubb:
Setting capabilities on shell scripts is not a very nice thing though it is a legal operation so this is not a bug

Comment 3 Steve Grubb 2011-08-17 16:37:58 UTC

I reviewed the test results I am getting with what you have above. Its looks like everything is OK. When it says expect failure and it says FAILED, then that is really passed. With the exception of the shell script failure being a bad test, everything seems to be fine. It took me a little while to see what the test was doing, but it seems ok.

Comment 4 Miroslav Vadkerti 2011-08-18 15:37:49 UTC

Thanks for looking into this. So there is no bug here and we can close this bug report as not a bug :)