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?

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

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.

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 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
ysnXUuU8b86TmdSXxHhm0YGgstqNsMtosfZkZlNPGbM5XpLkvl OjKCC4rr7Dq9YU
fbM36szMX9w2ktwkSWFrCVZnkzywTn2SzNZETkYxhGN45ttxUQ vGrg8/f0A0beiL
7MTgXHSBYD8HLquj7ML1AUz2+gPeX9BmK7AglaG+/aGi+05u+hXG0zrjNGGx8vvg
o06CYj3kKYpD3A4ShX/S2nhrLC7Lr/jB5bJB2Opv922oU++kYBuvsOT/bSNowdiS
hRTz5zqwQUU2HmP8sn/XrYlqpPZl8UxgP0Abisx8FP3q3ZhKPV+/tBo7q9v7X5aq
+bUTgR7IId4kHQOSjWYLMzgh24O4om/C5ZRR9p66KSPMoOKe3tZVte5OEnXEO86F
+VJ0HYEXK30+2pts0Ao0dvGa7NiMXyJhPtoD7IkTAB0ZIG4StY gZgwZ7JlX8fhaP
e+WCg4GaHnTWgKDr/ejmmfxPJg9gMtxGd2ee0s5Zc0UACOPErmGJrgow7vdwLOmQ
ByoACnftGWSrJAe5Iw6s6qEOnUR/5Sg8Z8qWvH/JfYqI94urXNqU/ivsU3hxPnxX
d89JUqqhyN1i3BUq4YmEpaKo+yno/9W0kYjlIrF+6pIW604Xaek+m/KiMp8HSndt
lERoBXb34v2REXyD8vdm
=widZ
-----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
w3YtQDpf66fgnVP9FN0ZBWnX4NIy0x3C2GAXDtTh8MXmY1g7dy vS9hkLdjZYeHPF
ShaWIQXXYtN1wkx2TLnrKY1weky5tqnzXiCMWX7UwbmgSizDnC OU7o+djH6klubB
bk5EEFlXL/njUm0+fPfNsMLn/xUrQzMSdIC7/IHjtlhJTj3wwDI+A8U1fDdSURXi
nngauqN/mtgXxpcQd2JrvDT47UvPlwuiAE1B4bRIgw3VgLbuYBdtatBhXJ x/a6ae
P21huF7RlLHJc2WMgfAdtQMlMUzZgLFjmcmY+stXB11W+rwisP gwnBNdJUEasLnx
lH60SejZ9eYA3LKNSSSxcVnwMkqsl8nrd4POArmt1g7mDMlZuD WMFRtDsMKrk7sl
01lpFxAkfxifq90c5PqjIKyhkT8EvJV0P0MlUXnCdiduT0qVMZ g79g1DTcikBNdg
qouAvwij2kUVF+fSMpMv54PvYX6M15aNAUkMTQxVoNRp9iGADu v8fZ6LVkiMpOPD
cpVPi9q3Te65zMWLWxX5dcvLLH/5/ApqCB/u7ZI0b1Vui7geob0KT0GoaEHJtJK5
Nsv+poMkn+UVsL8vsrRASuz2GWg3yRdcXBw01P4KvLsn1ete04 GR/NSvUib6S+5U
bDCbh+9ABJnFD4RoBP8d
=vK5o
-----END PGP SIGNATURE-----