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.