Why Is Capeff All Zeros in /Proc/$Pid/Status

Why is CapEff all zeros in /proc/$PID/status

A helpful person in #kernelnewbies on OFTC (irc) was kind enough to provide me with the answer.

ping sets cap_net_raw in the effective set, creates the socket, then drops cap_net_raw, as can been seen with strace:

$ strace -e socket,capset ping -c1 localhost
  capset({_LINUX_CAPABILITY_VERSION_3, 0}, {CAP_NET_RAW, CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0
  socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
  capset({_LINUX_CAPABILITY_VERSION_3, 0}, {0, CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0

Once the socket is open, no more privileges are required to write to it.

How to find out what linux capabilities a process requires to work?

Based on recent libcap2 update

1: (Short option): getpcaps

Description:

From here:

getpcaps displays the capabilities on the processes indicated by the
pid value(s) given on the command line.

Example:

$ getpcaps <PID>
PID: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+i

---

2: (A bit longer option): /proc status and capsh

Description:

proc is a process information pseudo-filesystem or in other words - a directory where you can view information on all processes.

About capsh:

Linux capability support and use can be explored and constrained with
this tool. This tool provides a handy wrapper for certain types of
capability testing and environment creation.
It also provides
some debugging features useful for summarizing capability state.

Example:

$ cat /proc/<PID>/status | grep Cap

And you'll get (on most systems):

CapInh: 00000000a80425fb (Inherited capabilities)
CapPrm: 0000000000000000 (Permitted capabilities)
CapEff: 0000000000000000 (Effective capabilities)
CapBnd: 00000000a80425fb (Bounding set)
CapAmb: 000000000000000  (Ambient capabilities set)

Use the capsh utility to decode from hexadecimal numbers into the capabilities name:

capsh --decode=00000000a80425fb
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

(*) You can download capsh with: sudo apt-get install git libpcap-dev.

Trying to implement HeapSort

Most of your problems seem to be in your HeapSort routine:

void HeapSort(int data[]) {
  BuildMaxHeap(data);
  for (int j = sizeof(data); j > 0; j--) {

When you pass an array to a function like this, what the function receives is actually a pointer. Using sizeof on that pointer will not tell you about the size of the data pointed to by the pointer -- it'll just tell you how many bytes the pointer itself occupies (typically 4). You probably want to pass the array size as a parameter:

void HeapSort(int *data, size_t data_size) {

and throughout the rest of the routine, you'll refer to data_size, not sizeof(data).

int temp = data[0];
data[0] = data[data.sizeof() - 1];
data[sizeof(data) - 1] = temp;
sizeof(data) = sizeof(data) - 1;

sizeof(whatever) is also essentially a constant, not a variable; you can't use it as the target of an assignment (but, again, using data_size as suggested above will let you do the assignment).

running a container with runAsNonRoot and add capabilities

This is the expected behavior. The capabilities are meant to divide the privileges traditionally associated with superuser (root) into distinct units; a non-root user cannot enable/disable such capabilities, that could create a security breach.

The capabilities feature in the SecurityContext key is designed to manage (either to limit or to expand) the Linux capabilities for the container's context; in a pod run as a root this means that the capabilities are inherited by the processes since these are owned by the root user; however, if the pod is run as a non-root user, it does not matter if the context has those capabilities enabled because the Linux Kernel will not allow a non-root user to set capabilities to a process.

This point can be illustrated very easily. If you run your container with the key runAsNonRoot set to true and add the capabilities as you did in the manifest shared, and then you exec into the Pod, you should be able to see those capabilities added to the context with the command:

$ capsh --print
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_time,cap_mknod,cap_audit_write,cap_setfcap+i
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_time,cap_mknod,cap_audit_write,cap_setfcap

But you will see the CapPrm or CapEff set to x0 in any process run by the user 1001:

$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1001           1  0.0  0.0   4340   760 ?        Ss   14:57   0:00 /bin/sh -c node server.js
1001           7  0.0  0.5 772128 22376 ?        Sl   14:57   0:00 node server.js
1001          21  0.0  0.0   4340   720 pts/0    Ss   14:59   0:00 sh
1001          28  0.0  0.0  17504  2096 pts/0    R+   15:02   0:00 ps aux
$ grep Cap proc/1/status
CapInh: 00000000aa0425fb
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000aa0425fb
CapAmb: 0000000000000000

---

Related Topics