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. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
