discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10


From: ematlis
Subject: Re: [Discuss-gnuradio] non root access to usrp2 on Fedora 10
Date: Tue, 2 Dec 2008 19:10:36 -0500 (EST)
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)

Thank you very much for your response. If I wanted to provide access through suid, which file should be set suid?


On Tue, 2 Dec 2008, Michael Ossmann wrote:

On Tue, Dec 02, 2008 at 03:41:35PM -0500, address@hidden wrote:

Hi all, I looked over the wiki and the mailing list but could not find
mention of how to access the usrp2 as a non-root user on Fedora 10.

As root, I get the following response from "find_usrps":

00:50:c2:85:30:68 hw_rev = 0x0300

but as a user, I get:

socket(PF_PACKET, SOCK_RAW, htons(0xBEEF)): Operation not permitted
eth0: socket: No such file or directory
No USRP2 found.

The code that talks to the USRP2 uses raw socket access (SOCK_RAW)
on the ethernet port.  This allows the use of a custom ethertype
rather than building on a higher level protocol like IP or UDP.  The
kernel does not allow anyone but root to use raw sockets.  This is
unlikely to change any time soon.  There has been some
discussion/experimentation over the last few years on various means
of providing ACLs to allow non-root raw socket access, but I don't
believe there is anything stable.  Other tools that use raw sockets
must also be run as root or are suid (like ping).

It is possible that the USRP2 could be modified in the future to use
a higher level protocol that would permit non-root access.  I
believe this has been discussed, but I don't know if anyone is
working on it.  Such a modification would come at the cost of
additional packet header overhead and would also require quite a bit
more networking code running on the USRP2 (I presume in the FPGA).

For the foreseeable future, all USRP2 access must run as root.  You
could use suid (dangerous) or sudo (maybe a little less dangerous)
to allow non-root users to execute stuff as root, but it is always a
security risk to allow non-root users to execute
unstable/development code as root.  Another option might be to use
some sort of virtualization to give root access only on a virtual
machine and not the host OS; I believe that would work in vmware
with a bridged ethernet interface, but I'm not sure about other
virtualization tools.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]