Daenyth Blank wrote:

On Wed, Nov 4, 2009 at 10:14, Daenyth Blank wrote:

...

On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar wrote:

...

so can this be done by default? thus reducing setuid usage? it should improve security right?

This should probably go on the bug tracker as a feature request.

Actually, the article states that not all file systems support this, so I don't think that it should be put in as the default. I think that it deserves mention on the wiki, however.

I writed an article in the wiki [#1] some time ago, for all common setuids in core packages and xorg about this. Some will fail and make more unsafe than safer (like mount) [#1] http://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setui... -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

On Wed, Nov 4, 2009 at 3:15 PM, Jan de Groot wrote:

On Wed, 2009-11-04 at 20:42 +0530, Shridhar Daithankar wrote:

...

Hi,

I was reading thr. /. commentary on the latest linux kernel bug, got drifted into file system capabilities. and got this, (from http://lwn.net/Articles/313838/)

[root@presario shridhar]# ls -la /bin/ping -rwsr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping [root@presario shridhar]# chmod u-s /bin/ping [root@presario shridhar]# setcap cap_net_raw=ep /bin/ping [root@presario shridhar]# ls -al /bin/ping -rwxr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping [root@presario shridhar]# exit shridhar@presario ~$ ping 192.168.1.5 PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data. 64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.219 ms 64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.354 ms ^C --- 192.168.1.5 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.219/0.286/0.354/0.069 ms

so can this be done by default? thus reducing setuid usage? it should improve security right?

This can be done by default, but capabilities aren't preserved when making tarballs. Every capability has to be set from post_install/post_upgrade in such cases. Maybe this is something worth to implement though.

Just in case someone knows, does star preserve capabilities, I'm under the impression it does a better job on ACLs and other file system flags than tar? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

Jan de Groot schrieb:

This can be done by default, but capabilities aren't preserved when making tarballs. Every capability has to be set from post_install/post_upgrade in such cases. Maybe this is something worth to implement though.

Actually, bsdtar preserves them when packing, but upon extracting they are gone. I don't know if we can force pacman to make this work. Maybe, maybe not. On another note: This [1] is something about fs caps, but "part two" didn't get finished, although it's November already. I have some code written to work with capabilities more (capchroot, capsudo), you can find the current status on http://projects.archlinux.org/. capchroot has a crappy config parser, capsudo is better but suffers from some small problems whose details I forgot. Both work though. I was going to explain those tools on "part two", but as I said, I haven't written it yet. [1] http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux-part...