[arch-general] must be root to ping?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, Did I miss something? I now have to use sudo in order to ping: graton% ping 10.1.0.1 ping: icmp open socket: Operation not permitted graton% sudo ping 10.1.0.1 PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data. 64 bytes from 10.1.0.1: icmp_req=1 ttl=64 time=0.407 ms 64 bytes from 10.1.0.1: icmp_req=2 ttl=64 time=0.367 ms 64 bytes from 10.1.0.1: icmp_req=3 ttl=64 time=0.345 ms 64 bytes from 10.1.0.1: icmp_req=4 ttl=64 time=0.361 ms ^C - --- 10.1.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2997ms rtt min/avg/max/mdev = 0.345/0.370/0.407/0.022 ms I thought maybe this was related to the glibc mess, so I finished cleaning that up (now everything is in /usr/lib with a symbolic link created for /lib), but that annoyance made no difference. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAYYJAAoJELT202JKF+xpJPgP/AhURBfrWADG1eR7Pt2dhaXD twMwg4XSV9FzYM3AMZp4frTRAt/oYIZDD/VXxg6BNoJAt+woKoPI+8Zlj4b2ndNJ DaSBf5ckJAYVHrRzNH3OuCxOudGzPZ9mrJBEpH7SVzx6IOEYSL3U+rRbWrMo0uYf utwpOhbJX2d4EuTggWoON8Iayglz/UB4SQJAuO3gm9+/cDGk6s/1is0n1k42t0iA J84FfH4XUdvDZoJl6f2pAq4tV+Xv2IGnsCWWEh6/ry59r4q5vv2j00K4BWy8DwA4 078bPW24kGR1uRipVW9RvmEa9SkQJ4F35+YoJF4vXU7nOqpLrrObOX0eYwQCT5s5 wsO6FkQvzUiDmL6t2/l2VhCd6KUsWXowR4gyslx4+064SYO2OIfA1ikwxpwMAUJO JXuj3AApauw96QAk//aHI0823WIkS32nh1yhtwBqofoKz3RG91nRsTJfHt1q9f7H etN2D1BRx8MHsTyetPNP8uEu7zLgieA4OXvJr0fAV3RHZFTZLE1RKJF6SpdafCBc UzobDRWBNz31mF5GepLAgsfctTlmy3em336o65voVjdmRdKuTLFkLPIhCaEY7s92 h3pnr3wyxH9KuP50s8wCjJYvD63wSfWbo7kCrsI+C9fqHQ4DTrYTNscioT+Gw8Os vXrWn3f3bH8PjbZSyNyw =l0bB -----END PGP SIGNATURE-----
Am 14.07.2012 16:45, schrieb David Benfell:
Hey all,
Did I miss something? I now have to use sudo in order to ping:
No idea how you broke this, but this should fix it: setcap cap_net_raw=ep /usr/bin/ping
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 08:06, Thomas Bächler wrote:
setcap cap_net_raw=ep /usr/bin/ping
I have no idea how I broke it either, but this definitely fixed it. Thanks! - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeTYAAoJELT202JKF+xpnkAP/0EfLyOn5Uo8RGhVuX1HlZxG ysnXUuU8b86TmdSXxHhm0YGgstqNsMtosfZkZlNPGbM5XpLkvlOjKCC4rr7Dq9YU fbM36szMX9w2ktwkSWFrCVZnkzywTn2SzNZETkYxhGN45ttxUQvGrg8/f0A0beiL 7MTgXHSBYD8HLquj7ML1AUz2+gPeX9BmK7AglaG+/aGi+05u+hXG0zrjNGGx8vvg o06CYj3kKYpD3A4ShX/S2nhrLC7Lr/jB5bJB2Opv922oU++kYBuvsOT/bSNowdiS hRTz5zqwQUU2HmP8sn/XrYlqpPZl8UxgP0Abisx8FP3q3ZhKPV+/tBo7q9v7X5aq +bUTgR7IId4kHQOSjWYLMzgh24O4om/C5ZRR9p66KSPMoOKe3tZVte5OEnXEO86F +VJ0HYEXK30+2pts0Ao0dvGa7NiMXyJhPtoD7IkTAB0ZIG4StYgZgwZ7JlX8fhaP e+WCg4GaHnTWgKDr/ejmmfxPJg9gMtxGd2ee0s5Zc0UACOPErmGJrgow7vdwLOmQ ByoACnftGWSrJAe5Iw6s6qEOnUR/5Sg8Z8qWvH/JfYqI94urXNqU/ivsU3hxPnxX d89JUqqhyN1i3BUq4YmEpaKo+yno/9W0kYjlIrF+6pIW604Xaek+m/KiMp8HSndt lERoBXb34v2REXyD8vdm =widZ -----END PGP SIGNATURE-----
On Sat, Jul 14, 2012 at 5:45 PM, David Benfell <benfell@parts-unknown.org> wrote:
Did I miss something? I now have to use sudo in order to ping:
graton% ping 10.1.0.1 ping: icmp open socket: Operation not permitted
Crafting ICMP packets requires root privileges, yes. (I vaguely remember Linux adding a separate socket type[0][1] for ICMP, but apparently it's not being used by `ping` yet.) `/usr/bin/ping` and `ping6` must be either setuid-root (chmod u+s) or have the CAP_NET_RAW capability (setcap cap_net_raw+ep). The Arch `iputils` package normally runs `setcap` in its post-install script[2]. [0]: http://lwn.net/Articles/420799/ [1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c319... [2]: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/iputils.inst... -- Mantas Mikulėnas
la, 2012-07-14 kello 18:07 +0300, Mantas Mikulėnas kirjoitti:
`/usr/bin/ping` and `ping6` must be either setuid-root (chmod u+s) or have the CAP_NET_RAW capability (setcap cap_net_raw+ep). The Arch `iputils` package normally runs `setcap` in its post-install script[2].
I just updated my system and got his message and now my ping is not working as regular user. ------------------------------------------------------------------------ (10/22) päivitetään iputils [#####################################] 100% Failed to set capabilities on file `usr/bin/ping' (Operation not supported) usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ] Note <filename> must be a regular (non-symlink) file. Failed to set capabilities on file `usr/bin/ping6' (Operation not supported) usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ] Note <filename> must be a regular (non-symlink) file.
Traceroute is now provided by core/traceroute
Running "sudo setcap cap_net_raw+ep /usr/bin/ping" manually results in the same (Operation not supported) error.
On Sat, Jul 14, 2012 at 6:13 PM, Jesse Juhani Jaara <jesse.jaara@gmail.com> wrote:
Running "sudo setcap cap_net_raw+ep /usr/bin/ping" manually results in the same (Operation not supported) error.
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too. -- Mantas Mikulėnas
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
Am 14.07.2012 17:23, schrieb Jesse Juhani Jaara:
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
This is getting weird. ext4 definitely supports file capabilities.
Am 14.07.2012 17:47, schrieb Thomas Bächler:
Am 14.07.2012 17:23, schrieb Jesse Juhani Jaara:
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
This is getting weird. ext4 definitely supports file capabilities.
Custom kernel maybe?
la, 2012-07-14 kello 18:05 +0200, Thomas Bächler kirjoitti:
Custom kernel maybe?
Actually yesm and a higly stipped down one.. Taking a look ot the kernl config it seems I have disabbled 'Security labels' on ext4 module. COuld this be the reason?
Am 14.07.2012 18:26, schrieb Jesse Juhani Jaara:
la, 2012-07-14 kello 18:05 +0200, Thomas Bächler kirjoitti:
Custom kernel maybe?
Actually yesm and a higly stipped down one.. Taking a look ot the kernl config it seems I have disabbled 'Security labels' on ext4 module. COuld this be the reason?
I think so, yes.
la, 2012-07-14 kello 18:38 +0200, Thomas Bächler kirjoitti:
Actually yesm and a higly stipped down one.. Taking a look ot the kernl config it seems I have disabbled 'Security labels' on ext4 module. COuld this be the reason? I think so, yes.
I enabled the Security labels on the kernel and it working fine now. The kernel config's help message isin't very clear, as starts by refering to SeLinux and other security modules (AppAmor,TOMOYo...) ....
Am 14.07.2012 18:58, schrieb Jesse Juhani Jaara:
I enabled the Security labels on the kernel and it working fine now. The kernel config's help message isin't very clear, as starts by refering to SeLinux and other security modules (AppAmor,TOMOYo...)
Yes, that message was written before Linux had file capabilities.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 09:05, Thomas Bächler wrote:
Am 14.07.2012 17:47, schrieb Thomas Bächler:
Am 14.07.2012 17:23, schrieb Jesse Juhani Jaara:
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
This is getting weird. ext4 definitely supports file capabilities.
Custom kernel maybe?
Not in my case. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeVCAAoJELT202JKF+xpr00P/2RaSXSUYJSSvsIDkwzofF0W gtFxbFIAO1KPf190gfU2j8ji9GbRf+iG/d92H5fONKzqgkiN6D276sN9huejB9Wj BOHfJliCKCNk/aceNZnk/Q9z6FEsB7XdRpQgF16MfYn+ogsO7xkiwGhitmlU4Thk EK9OqlR69XPe3VbtP2OoB46LS5XsaBrFUaY77J4FU6i+DUDTlcSVRiJN27/zGUPz PHgAmWJ4uRSWAxjtYG1abMoi4cWKuXQvwO6OEH2r++sb+2ED97Vw3oxJQwNVLilr 3DNiwUdH2HqT6mhEZQn3tRncgQaX1B4nf7S92N7UMggsoOGofzTMeEAe50XZdSvD YCwz8oRUtPOmqJlvlAAiy0rxAKGs2X515FMmFbDEF773uG2Mb+FCklF8uuMthXDS kMR7w1h7RKJUQkDxdIvhVeMBNbzXkmIMCwY1xxPKB5Ur/WIogUr8li5n8GqSv5/Z mXyK0hxcYaIyhRI0nu1cpciYTNg2+8t8dkULTTRo79sOB+lu3ZEZWbVZ0y4dTCUJ wx8UM4RnKZoeYZtxQBNU4ZrZIWzPFksamkjs3P+F9MrZyBd/kmGr7NdSXPrqwjBx EmeOFUS3wrrFqf/JuHKkxcpv2F0XYCDgBEX6pLR00Qv/JY7q8rcsp8FGbmfkiQO7 ewIEiDOCyiLLQ+ucAgWw =dbnW -----END PGP SIGNATURE-----
On 14-07-2012 16:23, Jesse Juhani Jaara wrote:
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
Is the partition mounted with nosuid? -- Mauro Santos
la, 2012-07-14 kello 17:00 +0100, Mauro Santos kirjoitti:
Is the partition mounted with nosuid? Nope.
On 14-07-2012 17:03, Jesse Juhani Jaara wrote:
la, 2012-07-14 kello 17:00 +0100, Mauro Santos kirjoitti:
Is the partition mounted with nosuid? Nope.
Jumped the gun too fast, after reading a bit of the man pages I'd say extended attributes might be to blame. The output of 'dumpe2fs -h /path/to/partition' may be of some help. The only filesystem attribute that seem to me to be related with this problem is 'ext_attr'. I'm not sure if mounting with nouser_xattr might have some influence. One funny thing is that 'man capabilities' says: "The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability." 'attr -l /usr/bin/ping' lists 'capability' as an attribute, however neither 'attr -g capability /usr/bin/ping' or 'attr -g security.capability /usr/bin/ping' can get the stored value. 'getcap /usr/bin/ping' does return the correct value. Things work fine for me but it seems that either the man page is not completely up-to-date, I'm missing something or less likely there is a bug somewhere. -- Mauro Santos
On Sat, Jul 14, 2012 at 7:35 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
I'm not sure if mounting with nouser_xattr might have some influence.
Unlikely. As you noted below, the capabilities are stored in security.* namespace, while `user_xattr` only affects the user.* namespace.
One funny thing is that 'man capabilities' says: "The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability."
'attr -l /usr/bin/ping' lists 'capability' as an attribute, however neither 'attr -g capability /usr/bin/ping' or 'attr -g security.capability /usr/bin/ping' can get the stored value. 'getcap /usr/bin/ping' does return the correct value.
The `attr` tool, coming from XFS, deals /only/ with attributes in the user.* namespace. `attr -g security.capability` will try to show you "user.security.capability". Use `getfattr` for the rest: $ getfattr -d -m "-" ping # file: ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= See attr(5) for xattr namespaces. -- Mantas Mikulėnas
On 14-07-2012 19:02, Mantas Mikulėnas wrote:
On Sat, Jul 14, 2012 at 7:35 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
I'm not sure if mounting with nouser_xattr might have some influence.
Unlikely. As you noted below, the capabilities are stored in security.* namespace, while `user_xattr` only affects the user.* namespace.
One funny thing is that 'man capabilities' says: "The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability."
'attr -l /usr/bin/ping' lists 'capability' as an attribute, however neither 'attr -g capability /usr/bin/ping' or 'attr -g security.capability /usr/bin/ping' can get the stored value. 'getcap /usr/bin/ping' does return the correct value.
The `attr` tool, coming from XFS, deals /only/ with attributes in the user.* namespace. `attr -g security.capability` will try to show you "user.security.capability".
Use `getfattr` for the rest:
$ getfattr -d -m "-" ping # file: ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
See attr(5) for xattr namespaces.
Mystery solved :) I missed the pattern option for getfattr, so the "I'm missing something" applies, as is usually the case. -- Mauro Santos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 11:02, Mantas Mikulėnas wrote:
getfattr -d -m "-" ping
I've already run setcap, but.... graton% getfattr -d -m "-" $(which ping) getfattr: Removing leading '/' from absolute path names # file: usr/bin/ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeZlAAoJELT202JKF+xp16EP/jBTrwFbjjfR0eWClfFaFOQk nMY0UJ++2CW0JGblUH3pVz36nyTdCh8uJqzgpUn5VEnpGI/yHU42g6QrV2bmEpJJ ZRNooPAJ1ALUhMkGEME5UzO8YPhebIrwonDIyqNtHQYrBrXBD/o6VbshbQgvgSXa WftYf3mwfGtHP3ds4JlMSFhzH0jhyeQCbLmJOnsFXNT4bRyFBAiFmHJ+TQT0hMwr JcA4d1o+DBycO1ub0PrQ7nODGKNk6Ep102jpHCneFly4uR5NSI8G0BCvgZpZXaG+ yEQ2udxLAgI3qIXnUHFpUmejcPvgM9jaJk0mOGBygHCfnvassieCE/uxHnuIxSus 2jp7YPFq9r5Dn3S/Z1iuMtd0hN+xwYCJHBXp4EDwyDLj+Ycv/ucxKc0AHYSfR65b ed9m/QPfcEww+vT+FXk0SnZp49ao1F06arQNQdWUyh4RiblcZ6G7XZcJcwV/lMcV XDUX6QJFHGBj+LOZgSq7K3h/jX0E0scLrNRmLXmAsNUzka8J9hrDiIGuOYzOarGj IuY3QR8WBMQW99kjCovuGmqvBgRU1qgj4XwMFBGsYQ5hVEeMLhy7qlVLB031CsM9 x+tw8FzJ9i4mR0Gm3LQtjdba6WCUk9xhgJ6etNboXYdwsWYoyMOrpPpSSNU3RwXb AJpoxzjQbO4g0eljGr3K =3JQP -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 09:35, Mauro Santos wrote:
dumpe2fs -h
That yields: graton% sudo dumpe2fs -h /dev/sda3 dumpe2fs 1.42.4 (12-June-2012) Filesystem volume name: <none> Last mounted on: / Filesystem UUID: a7f84383-2cc2-4d70-adb5-3bf909a3f99b Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1522928 Block count: 6115855 Reserved block count: 305790 Free blocks: 1553471 Free inodes: 1174323 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 468 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8144 Inode blocks per group: 509 RAID stride: 32596 Flex block group size: 16 Filesystem created: Wed May 30 00:29:50 2012 Last mount time: Sat Jul 14 07:31:58 2012 Last write time: Sat Jul 14 07:31:57 2012 Mount count: 12 Maximum mount count: -1 Last checked: Thu May 31 03:15:25 2012 Check interval: 0 (<none>) Lifetime writes: 62 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 1172773 Default directory hash: half_md4 Directory Hash Seed: 7101382d-74b1-43e1-a163-f8922fa6b38b Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x0004ca75 Journal start: 16395 - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeYTAAoJELT202JKF+xpVRgP/RMim6ye1/x3q7YEBqAFeZQN geM2aXZlvU+zg8DyWE4TSYtzgJIQYKw0c2K8wAeiaEQF9wly1LlRXO3BxJSnFW/k DJ9/KVutrs3lKXxNLy9RFbbVO+q/G0ZN7vMHcFdEpq/7oQ18ZFDAd+P8MbyYvEAD jH4GWyhk13/L418B3Az1QpOzLJO2XDHw1x7awYyUEO8yHnftyvzxrO9vIo+7ueyd GXktIuM7Swk+JcHjMpXAh9yeekKErcGQgG6EYqUtm8IYD7H1f7++amCXkitjBmd7 ADDULIKlZ/NbzokFDYL0ZS+cCD/9gSFpDqM8oW9S58OfUpkC/M7XO8n4QGX+xDUl 0ceBwyVNdQzFXx2mj3KM4x1z3e9iEig8uXnTOx19A32S2kB8SHViSKLrIsCVf6kv ktQklH+nuYBzw3oL6+Hov6iiAqcZCbbsir1TdcwSXIoLFXnjZJCIav2Izd2hY066 OIPg9T6RL6tQ+lyKUEldUI89TdDWICmW11FTrXm/eCTaQtjiL1gOqbPqc80K7kKi yh9G2kpYA9vqB1K9EQpKS6PySHx/G/kVoYv8RzX+dqAr/OOKJgoP4iiN0OIzPTtT RXyBuByR7bWMRLJwObBWc+Wpit9tcIIjmFm75yYCIDX9dmGSDZHjRivvI2yDvT8P gojExvupdI90NyVjKbmF =1XJd -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 09:00, Mauro Santos wrote:
On 14-07-2012 16:23, Jesse Juhani Jaara wrote:
la, 2012-07-14 kello 18:22 +0300, Mantas Mikulėnas kirjoitti:
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
Ext4
Is the partition mounted with nosuid?
The best way for me to answer this is with: graton% mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) dev on /dev type devtmpfs (rw,nosuid,relatime,size=2893424k,nr_inodes=723356,mode=755) run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) /dev/sda3 on / type ext4 (rw,relatime,data=ordered) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime) /dev/sda1 on /boot type ext2 (rw,relatime) /dev/sda4 on /home type ext4 (rw,relatime,data=ordered) /dev/sdb1 on /storage/n4rky type ext4 (rw,relatime,data=ordered) /dev/sdb2 on /storage/graton type ext4 (rw,relatime,data=ordered) /dev/sdb3 on /storage/atlanta type ext4 (rw,relatime,data=ordered) binfmt on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) gvfs-fuse-daemon on /home/benfell/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=100) graton% I believe the answer is no--or else I'd be having a lot of other problems. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeW/AAoJELT202JKF+xpY9EP/i2nxuUvN8cprtsGiU/ahAm9 oBsanJrJZVWrDzbxMnq6T8Q7dmBVLuxalQNny2z1zuI53GjKmDIZm5YZV7Il0kiJ dIXj7rhkk6c5a1EnwUb3S29ZLJilj6rPk1VxEuAzwvYBlLvda3UGgcPj+WD1YMF0 5wL0AWh2FHgmlNPZ2iZ3wxXWd9mmF1yzZXFiB9I7IkcAL5ifP6dqGqiVqhGhIXVM c9LGcdWxU/5xSdtM1lovOIQQJ0bMYSFks67402wrmOvSE42eCD2aHQLq5EKYB9T1 LwexC1HyT7qRB0sYr9HPv3eqsQzH/09ZpuZfGYxro9v1PfcGbHuCaGhcFsBcOaCC QEvuYq0aGk8xsKfLbLLUI0X7sFnOSBgtgF7Vd8PiIWn2S4QxtGNMyt8HWh/x81/l iJTXE+Gm1XYrhbL4ON0t/fzo68Yhl5J1iv1cQja1lCT0sVfPkpmHLxxVmUOYFGLU x4Qk4LSZ9DBSxKg3Ta4x86zBSNr+fG2MaczmjyA+/J4aecPnfalhBC0IKCq/GcGV osp0TK3/wlWyE1B4Nk4dM2AOLduIs8wfJI+wEPMo+EVr6M7J4dJ7JnAiRjN2kbzV i8XSLg3PxpMtZM1529HZ+sdK1XY+q8KFsqS9TGHtinfjvR/ttLNGfXov3g8ZLgql dUwXRZ2s2/SBlhawPZsj =2OC8 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/12 08:22, Mantas Mikulėnas wrote:
On Sat, Jul 14, 2012 at 6:13 PM, Jesse Juhani Jaara <jesse.jaara@gmail.com> wrote:
Running "sudo setcap cap_net_raw+ep /usr/bin/ping" manually results in the same (Operation not supported) error.
Which filesystem is your /usr using? Not all file systems support storing capabilities... though the error might be caused by something else, too.
I'm pretty sure iputils was upgraded recently, so somehow that must have failed then. I'm using ext4 and the setcap command seems to have worked. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQAeUkAAoJELT202JKF+xpD+YP/0oDEnMivhyKkgSL76zor2R2 w3YtQDpf66fgnVP9FN0ZBWnX4NIy0x3C2GAXDtTh8MXmY1g7dyvS9hkLdjZYeHPF ShaWIQXXYtN1wkx2TLnrKY1weky5tqnzXiCMWX7UwbmgSizDnCOU7o+djH6klubB bk5EEFlXL/njUm0+fPfNsMLn/xUrQzMSdIC7/IHjtlhJTj3wwDI+A8U1fDdSURXi nngauqN/mtgXxpcQd2JrvDT47UvPlwuiAE1B4bRIgw3VgLbuYBdtatBhXJx/a6ae P21huF7RlLHJc2WMgfAdtQMlMUzZgLFjmcmY+stXB11W+rwisPgwnBNdJUEasLnx lH60SejZ9eYA3LKNSSSxcVnwMkqsl8nrd4POArmt1g7mDMlZuDWMFRtDsMKrk7sl 01lpFxAkfxifq90c5PqjIKyhkT8EvJV0P0MlUXnCdiduT0qVMZg79g1DTcikBNdg qouAvwij2kUVF+fSMpMv54PvYX6M15aNAUkMTQxVoNRp9iGADuv8fZ6LVkiMpOPD cpVPi9q3Te65zMWLWxX5dcvLLH/5/ApqCB/u7ZI0b1Vui7geob0KT0GoaEHJtJK5 Nsv+poMkn+UVsL8vsrRASuz2GWg3yRdcXBw01P4KvLsn1ete04GR/NSvUib6S+5U bDCbh+9ABJnFD4RoBP8d =vK5o -----END PGP SIGNATURE-----
Ping requires/uses setuid. Probably, the new update was not compiled properly. On 14-Jul-2012 8:27 PM, "David Benfell" <benfell@parts-unknown.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
Did I miss something? I now have to use sudo in order to ping:
graton% ping 10.1.0.1 ping: icmp open socket: Operation not permitted graton% sudo ping 10.1.0.1 PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data. 64 bytes from 10.1.0.1: icmp_req=1 ttl=64 time=0.407 ms 64 bytes from 10.1.0.1: icmp_req=2 ttl=64 time=0.367 ms 64 bytes from 10.1.0.1: icmp_req=3 ttl=64 time=0.345 ms 64 bytes from 10.1.0.1: icmp_req=4 ttl=64 time=0.361 ms ^C - --- 10.1.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2997ms rtt min/avg/max/mdev = 0.345/0.370/0.407/0.022 ms
I thought maybe this was related to the glibc mess, so I finished cleaning that up (now everything is in /usr/lib with a symbolic link created for /lib), but that annoyance made no difference.
- -- David Benfell benfell@parts-unknown.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQAYYJAAoJELT202JKF+xpJPgP/AhURBfrWADG1eR7Pt2dhaXD twMwg4XSV9FzYM3AMZp4frTRAt/oYIZDD/VXxg6BNoJAt+woKoPI+8Zlj4b2ndNJ DaSBf5ckJAYVHrRzNH3OuCxOudGzPZ9mrJBEpH7SVzx6IOEYSL3U+rRbWrMo0uYf utwpOhbJX2d4EuTggWoON8Iayglz/UB4SQJAuO3gm9+/cDGk6s/1is0n1k42t0iA J84FfH4XUdvDZoJl6f2pAq4tV+Xv2IGnsCWWEh6/ry59r4q5vv2j00K4BWy8DwA4 078bPW24kGR1uRipVW9RvmEa9SkQJ4F35+YoJF4vXU7nOqpLrrObOX0eYwQCT5s5 wsO6FkQvzUiDmL6t2/l2VhCd6KUsWXowR4gyslx4+064SYO2OIfA1ikwxpwMAUJO JXuj3AApauw96QAk//aHI0823WIkS32nh1yhtwBqofoKz3RG91nRsTJfHt1q9f7H etN2D1BRx8MHsTyetPNP8uEu7zLgieA4OXvJr0fAV3RHZFTZLE1RKJF6SpdafCBc UzobDRWBNz31mF5GepLAgsfctTlmy3em336o65voVjdmRdKuTLFkLPIhCaEY7s92 h3pnr3wyxH9KuP50s8wCjJYvD63wSfWbo7kCrsI+C9fqHQ4DTrYTNscioT+Gw8Os vXrWn3f3bH8PjbZSyNyw =l0bB -----END PGP SIGNATURE-----
participants (6)
-
David Benfell
-
Jayesh Badwaik
-
Jesse Juhani Jaara
-
Mantas Mikulėnas
-
Mauro Santos
-
Thomas Bächler