Bug 730742 - quicktest.sh failures in libcap package
Summary: quicktest.sh failures in libcap package
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libcap
Version: 6.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Karsten Hopp
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-15 15:17 UTC by Miroslav Vadkerti
Modified: 2011-08-18 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-18 15:37:49 UTC


Attachments (Terms of Use)

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 :)


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