On 07/26/2011 03:05 PM, Tom Horsley wrote:
On Tue, 26 Jul 2011 14:54:18 +0100
Bryn M. Reeves wrote:
> As others have said, that's how rsh "security" "works" - if
you need to strace
> the command as a non-root user you might be able to come up with something
> involving dropping the file capability and granting cap_net_bind_service to the
> user you need to strace as (obviously this grants that user the ability to bind
> any port they like but for debugging you might chose to allow that).
I was looking for that, but can't find the slightest shred of evidence
that a user can be granted a capability in any of the googling I have
done. All I can find is setcap for granting a file capability.
There's a capsh command in the libcap package that lets you run a shell with a
modified set of capabilities but I'm not sure if it will help here - it's mostly
used for dropping caps for testing - I don't seem to be able to raise the
effective capabilities for a non-root uid:
[root@bmr ~]# capsh --keep=1 --uid=4444 --caps='
cap_net_raw,cap_net_bind_service+pei' --
[bmr@bmr ~]$ grep Cap /proc/self/status
CapInh: 0000000000002400
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
So the bits I asked for made it into the inherited capabilities mask but not the
permitted or effective (the +pi).. Not sure why this is - capabilities can be
configured so that once dropped they can never be regained via the bounding set
and prctl/PR_SET_SECUREBITS but I didn't think this was being done on Fedora yet?
Regards,
Bryn.