how to run as non-root user?


I am a new user of bro, and have recently install bro 0.9a9 on a Linux
box. I have a question with bro:

I want to run bro as non-root user, and have created an account for
bro. However, when I try to start bro with bro.rc, it reports "problem
with interface eth0 - pcap_open_live: socket: Operation not
permitted". Does it mean that I need to setuid bro binary? If so, does
bro drops privilege after pcap_open? (A quick grep shows that bro does
not call setuid()).

BTW, there is a small issue with bro.rc. It calls bro with "su -l
${alternate_user_id}...". On my system, the shell of root account is
tcsh. Then when I run bro.rc from an interactive root shell, it
prompts the error as follows:

   Unknown option: `-l'
   Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ].

To fix it, either I need to change root shell to bash (which is not
preferred IMHO), or change bro.rc as "su - ${alternate_user_id}...".



The issue you are seeing is related to how Linux does packet capture. In short
Linux must have root privilages to capture packets. Sorry, but without using
some of the custom kernel patches out there you must run Bro as a user that has
root privs. If you want more info search for linux packet capture.

As for bro.rc it was written for 'sh' and is compatible with 'bash'. That's why
the bang path is #!/bin/sh. bro.rc was written to work on the widest number of
systems possible and sh/bash are available everywhere.

I produced a simple shell script to simulate what you are referring to but was
unable to reproduce the error. brouser has a shell of /bin/tcsh and root has a
shell of /bin/tcsh


if [ "$1" = '1' ]; then
        echo DONE
        exit 0

su -l brouser -c "$0 1 < /dev/null"

If you can find more info on the error I will look into it further.


Jingmin Zhou wrote:

Hi there,

I'm a bit puzzled about the problem as well, because according to

> Unknown option: `-l'
> Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ].

-l should work. Also, at least with GNU coreutils it doesn't make any
difference whether you use 'su -' or 'su -l'. su puts the basename of
the shell of the user that is su'd to into argv[0], prefixed with '-' to
indicate a login shell.

Bash's and ksh's manpages mention this, tcsh's manpage is imprecise in
saying argv[0] has to *be* "-" but its code only checks for the first
character being '-' (or the -l flag, as the manpage says).


On my linux (debian) system, su shows this:

jason@foobar[3:07pm](205)> su -l foobar
su: invalid option -- l
Usage: su [OPTS] [-] [username [ARGS]]
        - make this a login shell
        -c, --command=<command>
                pass command to the invoked shell using its -c
       -m, -p, --preserve-environment
                do not reset environment variables, and keep the
                same shell
       -s, --shell=<shell>
                use shell instead of the default in /etc/passwd


Christian Kreibich wrote:

Cool, I guess that explains the problem then?! I had looked at coreutils
5.2.1, where su.c has -, -l, --login.