setcap settings do not reflect in getcap
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
root@localhost:~# setcap cap_net_raw+p /bin/ping
root@localhost:~# getcap /bin/ping
root@localhost:~# ls -l $(which ping)
-rwsr-xr-x. 1 root root 34752 Nov 8 2014 /bin/ping
root@localhost:~# ping localhost
ping: icmp open socket: Operation not permitted
root@localhost:~#
Looks like for some reason my setcap settings do not get reflected, any idea where I'm going wrong?
Details as requested by @meuh
root@localhost:~# for i in /proc/fs/*/*/options ;do echo $i=&&cat $i|grep user_xattr;done
/proc/fs/ext4/mmcblk0p16/options=
user_xattr
/proc/fs/ext4/mmcblk0p25/options=
user_xattr
/proc/fs/ext4/mmcblk0p27/options=
user_xattr
/proc/fs/ext4/mmcblk0p28/options=
user_xattr
root@localhost:~# mount|grep ext4
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (ro,seclabel,relatime)
/dev/block/platform/msm_sdcc.1/by-name/userdata on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered)
root@localhost:~# df -h --output
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
/dev/block/platform/msm_sdcc.1/by-name/userdata ext4 820K 35K 785K 5% 13G 1.4G 12G 12% - /data
tmpfs tmpfs 181K 486 181K 1% 928M 80K 928M 1% - /dev
none tmpfs 181K 6 181K 1% 928M 12K 928M 1% - /sys/fs/cgroup
tmpfs tmpfs 181K 22 181K 1% 928M 0 928M 0% - /mnt
root@localhost:~# df --output -h /bin/ping
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
rootfs rootfs 820K 35K 785K 5% 13G 1.4G 12G 12% /bin/ping /
debian ping root-filesystem setcap gnuroot
asked Apr 10 at 5:10
kaza
1012
 |Â
show 3 more comments
up vote
0
down vote
favorite
root@localhost:~# setcap cap_net_raw+p /bin/ping
root@localhost:~# getcap /bin/ping
root@localhost:~# ls -l $(which ping)
-rwsr-xr-x. 1 root root 34752 Nov 8 2014 /bin/ping
root@localhost:~# ping localhost
ping: icmp open socket: Operation not permitted
root@localhost:~#
Looks like for some reason my setcap settings do not get reflected, any idea where I'm going wrong?
Details as requested by @meuh
root@localhost:~# for i in /proc/fs/*/*/options ;do echo $i=&&cat $i|grep user_xattr;done
/proc/fs/ext4/mmcblk0p16/options=
user_xattr
/proc/fs/ext4/mmcblk0p25/options=
user_xattr
/proc/fs/ext4/mmcblk0p27/options=
user_xattr
/proc/fs/ext4/mmcblk0p28/options=
user_xattr
root@localhost:~# mount|grep ext4
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (ro,seclabel,relatime)
/dev/block/platform/msm_sdcc.1/by-name/userdata on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered)
root@localhost:~# df -h --output
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
/dev/block/platform/msm_sdcc.1/by-name/userdata ext4 820K 35K 785K 5% 13G 1.4G 12G 12% - /data
tmpfs tmpfs 181K 486 181K 1% 928M 80K 928M 1% - /dev
none tmpfs 181K 6 181K 1% 928M 12K 928M 1% - /sys/fs/cgroup
tmpfs tmpfs 181K 22 181K 1% 928M 0 928M 0% - /mnt
root@localhost:~# df --output -h /bin/ping
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
rootfs rootfs 820K 35K 785K 5% 13G 1.4G 12G 12% /bin/ping /
debian ping root-filesystem setcap gnuroot
asked Apr 10 at 5:10
kaza
1012
Perhaps your filesystem or mount does not supportuser_xattr. Look for this keyword in/proc/fs/*/sda1/optionswheresda1is the mounted disk.
– meuh
Apr 10 at 13:25
@meuh apologies for late reply, but I was trying to figure out thesda1you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)
– kaza
Apr 11 at 18:39
Your commanddf /bin/pingseems to show/is still of typerootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real/from a disk. Do you know how the system ended up this way?
– meuh
Apr 11 at 19:12
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
That said do you think, there is a relationship betweenext4androotfsas both have the sameInodesand usage stats...
– kaza
Apr 11 at 19:33
 |Â
show 3 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
root@localhost:~# setcap cap_net_raw+p /bin/ping
root@localhost:~# getcap /bin/ping
root@localhost:~# ls -l $(which ping)
-rwsr-xr-x. 1 root root 34752 Nov 8 2014 /bin/ping
root@localhost:~# ping localhost
ping: icmp open socket: Operation not permitted
root@localhost:~#
Looks like for some reason my setcap settings do not get reflected, any idea where I'm going wrong?
Details as requested by @meuh
root@localhost:~# for i in /proc/fs/*/*/options ;do echo $i=&&cat $i|grep user_xattr;done
/proc/fs/ext4/mmcblk0p16/options=
user_xattr
/proc/fs/ext4/mmcblk0p25/options=
user_xattr
/proc/fs/ext4/mmcblk0p27/options=
user_xattr
/proc/fs/ext4/mmcblk0p28/options=
user_xattr
root@localhost:~# mount|grep ext4
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (ro,seclabel,relatime)
/dev/block/platform/msm_sdcc.1/by-name/userdata on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered)
root@localhost:~# df -h --output
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
/dev/block/platform/msm_sdcc.1/by-name/userdata ext4 820K 35K 785K 5% 13G 1.4G 12G 12% - /data
tmpfs tmpfs 181K 486 181K 1% 928M 80K 928M 1% - /dev
none tmpfs 181K 6 181K 1% 928M 12K 928M 1% - /sys/fs/cgroup
tmpfs tmpfs 181K 22 181K 1% 928M 0 928M 0% - /mnt
root@localhost:~# df --output -h /bin/ping
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
rootfs rootfs 820K 35K 785K 5% 13G 1.4G 12G 12% /bin/ping /
debian ping root-filesystem setcap gnuroot
asked Apr 10 at 5:10
kaza
1012
root@localhost:~# setcap cap_net_raw+p /bin/ping
root@localhost:~# getcap /bin/ping
root@localhost:~# ls -l $(which ping)
-rwsr-xr-x. 1 root root 34752 Nov 8 2014 /bin/ping
root@localhost:~# ping localhost
ping: icmp open socket: Operation not permitted
root@localhost:~#
Looks like for some reason my setcap settings do not get reflected, any idea where I'm going wrong?
Details as requested by @meuh
root@localhost:~# for i in /proc/fs/*/*/options ;do echo $i=&&cat $i|grep user_xattr;done
/proc/fs/ext4/mmcblk0p16/options=
user_xattr
/proc/fs/ext4/mmcblk0p25/options=
user_xattr
/proc/fs/ext4/mmcblk0p27/options=
user_xattr
/proc/fs/ext4/mmcblk0p28/options=
user_xattr
root@localhost:~# mount|grep ext4
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (ro,seclabel,relatime)
/dev/block/platform/msm_sdcc.1/by-name/userdata on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered)
root@localhost:~# df -h --output
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
/dev/block/platform/msm_sdcc.1/by-name/userdata ext4 820K 35K 785K 5% 13G 1.4G 12G 12% - /data
tmpfs tmpfs 181K 486 181K 1% 928M 80K 928M 1% - /dev
none tmpfs 181K 6 181K 1% 928M 12K 928M 1% - /sys/fs/cgroup
tmpfs tmpfs 181K 22 181K 1% 928M 0 928M 0% - /mnt
root@localhost:~# df --output -h /bin/ping
Filesystem Type Inodes IUsed IFree IUse% Size Used Avail Use% File Mounted on
rootfs rootfs 820K 35K 785K 5% 13G 1.4G 12G 12% /bin/ping /
debian ping root-filesystem setcap gnuroot
asked Apr 10 at 5:10
kaza
1012
edited Apr 11 at 19:56
asked Apr 10 at 5:10
kaza
1012
asked Apr 10 at 5:10
kaza
1012
asked Apr 10 at 5:10
kaza
1012
1012
Perhaps your filesystem or mount does not supportuser_xattr. Look for this keyword in/proc/fs/*/sda1/optionswheresda1is the mounted disk.
– meuh
Apr 10 at 13:25
@meuh apologies for late reply, but I was trying to figure out thesda1you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)
– kaza
Apr 11 at 18:39
Your commanddf /bin/pingseems to show/is still of typerootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real/from a disk. Do you know how the system ended up this way?
– meuh
Apr 11 at 19:12
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
That said do you think, there is a relationship betweenext4androotfsas both have the sameInodesand usage stats...
– kaza
Apr 11 at 19:33
 |Â
show 3 more comments
Perhaps your filesystem or mount does not supportuser_xattr. Look for this keyword in/proc/fs/*/sda1/optionswheresda1is the mounted disk.
– meuh
Apr 10 at 13:25
@meuh apologies for late reply, but I was trying to figure out thesda1you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)
– kaza
Apr 11 at 18:39
Your commanddf /bin/pingseems to show/is still of typerootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real/from a disk. Do you know how the system ended up this way?
– meuh
Apr 11 at 19:12
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
That said do you think, there is a relationship betweenext4androotfsas both have the sameInodesand usage stats...
– kaza
Apr 11 at 19:33
Perhaps your filesystem or mount does not support
user_xattr. Look for this keyword in /proc/fs/*/sda1/options where sda1 is the mounted disk.– meuh
Apr 10 at 13:25
Perhaps your filesystem or mount does not support
user_xattr. Look for this keyword in /proc/fs/*/sda1/options where sda1 is the mounted disk.– meuh
Apr 10 at 13:25
@meuh apologies for late reply, but I was trying to figure out the
sda1 you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)– kaza
Apr 11 at 18:39
@meuh apologies for late reply, but I was trying to figure out the
sda1 you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)– kaza
Apr 11 at 18:39
Your command
df /bin/ping seems to show / is still of type rootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real / from a disk. Do you know how the system ended up this way?– meuh
Apr 11 at 19:12
Your command
df /bin/ping seems to show / is still of type rootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real / from a disk. Do you know how the system ended up this way?– meuh
Apr 11 at 19:12
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
That said do you think, there is a relationship between
ext4 and rootfs as both have the same Inodes and usage stats...– kaza
Apr 11 at 19:33
That said do you think, there is a relationship between
ext4 and rootfs as both have the same Inodes and usage stats...– kaza
Apr 11 at 19:33
 |Â
show 3 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Â
draft saved
draft discarded
Â
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f436682%2fsetcap-settings-do-not-reflect-in-getcap%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Perhaps your filesystem or mount does not support
user_xattr. Look for this keyword in/proc/fs/*/sda1/optionswheresda1is the mounted disk.– meuh
Apr 10 at 13:25
@meuh apologies for late reply, but I was trying to figure out the
sda1you mentioned, but failed to do so... I'm leaving output of a few commands that I think would help you, in helping me :-)– kaza
Apr 11 at 18:39
Your command
df /bin/pingseems to show/is still of typerootfs, which may not support extended attributes (i.e. capabilities). I'm not familiar with this situation, as normally during boot this temporary rootfs is overwritten by the mount of a real/from a disk. Do you know how the system ended up this way?– meuh
Apr 11 at 19:12
This is a debian side loaded in an android phone via play.google.com/store/apps/…. See github.com/corbinlc/GNURootDebian
– kaza
Apr 11 at 19:29
That said do you think, there is a relationship between
ext4androotfsas both have the sameInodesand usage stats...– kaza
Apr 11 at 19:33