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

[ematlis]

In terms of using sudo, there is some issue with the environment variables 
not being passed:

address@hidden ~]$ sudo usrp2_fft.py
[sudo] password for matlis:
sudo: usrp2_fft.py: command not found

address@hidden ~]$ sudo /usr/local/bin/usrp2_fft.py
execlp: couldn't exec usrp2_socket_opener: No such file or directory
eth0: socket: Bad file descriptor
Traceback (most recent call last):
  File "/usr/local/bin/usrp2_fft.py", line 267, in <module>
    main ()
  File "/usr/local/bin/usrp2_fft.py", line 263, in main
    app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
36, in __init__
    wx.App.__init__ (self, redirect=False)
  File 
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7935, in __init__
    self._BootstrapApp()
  File 
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7509, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
39, in OnInit
    frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
60, in __init__
    self.panel = stdpanel (self, self, top_block_maker)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
81, in __init__
    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "/usr/local/bin/usrp2_fft.py", line 68, in __init__
    self.u = usrp2.source_32fc(options.interface, options.mac_addr)
  File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py", line 
449, in source_32fc
    return _usrp2.source_32fc(*args)
RuntimeError: No USRPs found on interface eth0
eth0: socket: Operation not permitted
Traceback (most recent call last):
  File "/usr/local/bin/usrp2_fft.py", line 267, in <module>
    main ()
  File "/usr/local/bin/usrp2_fft.py", line 263, in main
    app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
36, in __init__
    wx.App.__init__ (self, redirect=False)
  File 
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7935, in __init__
    self._BootstrapApp()
  File 
"/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7509, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
39, in OnInit
    frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
60, in __init__
    self.panel = stdpanel (self, self, top_block_maker)
  File 
"/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 
81, in __init__
    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "/usr/local/bin/usrp2_fft.py", line 68, in __init__
    self.u = usrp2.source_32fc(options.interface, options.mac_addr)
  File "/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py", line 
449, in source_32fc
    return _usrp2.source_32fc(*args)
RuntimeError: No USRPs found on interface eth0


eric

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.