To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.15: Filesystem capabilities 0.16
References: <200601161916.k0GJGm7T002751@laptop11.inf.utfsm.cl>
From: Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>
Date: Sat, 21 Jan 2006 23:35:35 +0100
Message-ID: <87psml43bc.fsf@goat.bogus.local>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1456
Lines: 40

Sorry for the late response, I've been away for the week.

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

> Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de> wrote:
>> +	  For example, you may drop the SUID bit from ping and grant the
>> +	  CAP_NET_RAW capability:
>> +	  # chmod u-s /bin/ping
>> +	  # chcap cap_net_raw=ep /bin/ping
>
> Why the cap_ part? It should be enough to say, e.g.
>
>     chcap net-raw=ep /bin/ping
>
> ('_' has SHIFT, normally... '-' is easier to type)

This is the way libcap expects the capabilities string. I never
questioned the format of this string. But it isn't hard to do a simple
mapping.

>> +
>> +	  Another use would be to run system daemons with their own uid:
>> +	  # chcap cap_net_bind_service=ei /usr/sbin/named
>> +	  This sets the effective and inheritable capabilities of named.
>> +
>> +	  In your startup script:
>> +	  inhcaps cap_net_bind_service=i bind:bind /usr/sbin/named
>
> AFAIU, the =i implies inherited, why another command to set that?

Look for keep_capabilities in security/commoncap.c. If you do a
setuid() away from root, Linux drops all privileges. Inhcaps does a
setuid() and arranges for keeping the needed capabilities.

Regards, Olaf.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/