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

[ematlis]

Update-

making sudo chmod u+s /usr/local/bin/usrp2_socket_opener

allows usrp2_fft.py to work (also as suid) by a normal user.

thanks!

I would be interested in trying the sudo approach, but as I mentioned in 
my previous post there are some issues perhaps with sudo not knowing about 
the path or other environment variables.

eric

************************************
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
121 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355

On Wed, 3 Dec 2008, Michael Ossmann wrote:

> The libraries don't need to be suid, the executable (usrp2_fft.py)
> does.  Personally I think it would be easier to use sudo than to go
> around making lots of different executables suid root, but the suid
> method might be easier if you have a small list of executables that
> doesn't change much.
>
>
> On Wed, Dec 03, 2008 at 10:58:26AM -0500, address@hidden wrote:
> > If I want to run the example program usrp2_fft.py, which routines (python
> > and/or c++) need to be made suid?
> >
> > thanks,
> > eric
> >
> > On Tue, 2 Dec 2008, Michael Ossmann wrote:
> >
> > > find_usrps and any other front-end programs would need to be suid
> > > (have the suid bit set and be owned by root).
> > >
> > >
> > > On Tue, Dec 02, 2008 at 07:10:36PM -0500, address@hidden wrote:
> > > > 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.