the "need" to run as root

[karrde]

As I understand it, the "need" for seq to run as root is so that it can grab on to the NIC, set it to promiscous mode, and sniff the packets.

If that is the only reason has it ever been considered to split off the newtorking code into a seperate daemon, that would dump to a named pipe or somthing on tha machine, which the client (now running w/ only user perms) could just read off the data stream the the daemon is now spitting out.

If there are more reasons (that don't invlolve the file permissions of the /usr/local/share files) I'd like to know. I'm thinking about working on this in some of my spare time (not that I'm sure it really exists, spare time that is).

[S_B_R]

That's the only reason I know of. I don't think anyone has ever looked into a sniffer daemon version of SEQ. I don't see why it wouldn't work.

Personally I run SEQ on my Router/Firewall box so I don't need to run it in Promiscuous mode, so no root procs for me.

[Cryonic]

hmm, with it running as a sort of sniffer daemon that could be connected to via a network socket you could have your friends just run the sniffer part at their locs and you run the interface(s) at your house and you can watch what is happening to them even if you aren't with them at their house :)

[Zaphod]

You might be able to do something of this sort. Something will have to run as root, at least long enough to get a hold of the network device. One word of caution, I'm in the midst of revamping parts of EQPacket. I've already extracated the logging code, but now it's time for me to clean up some really ugly cruft in there. I'm hoping these major changes to EQPacket in either my next CVS commit, or the one after that.

Additional people helping on the code is always appreciated. So wether you start on this or some other project, kudos...

Thanks and Enjoy,
Zaphod (dohpaZ)

[perlmonkey]

So, just to cobble a rough hack out as an example (compiles, but untested), why not do this sort of priv-separation like sshd does:

(messy, large attachment deleted... someone clue me in on how to attach a patch, please)

Just a thought.

[perlmonkey]

Ok, it seems that you can't attach to an existing message, which is what was confusing me. Here's the patch I was proposing. I have *no* clue what the convetions are for adding new pref data, and I've probably done the *wrong* thing in many ways, but this just gives you the basic concept. If folks like the idea, I can make any changes that are required.

[perlmonkey]

And here it is in action:

$ src/showeq --privsep-user=daemon &
$ ps auxf | grep showeq
daemon 12754 8.9 1.7 54912 15896 pts/1 S 17:35 0:00 | \_ src/showeq --privsep-user=daemon

And it seems to run ok... I'll do more testing.

I'm re-attaching the patch. The original version had a small bug (no break in the command-line switch). It's a one-line fix.

[perlmonkey]

It's worthy of note that this patch has no effect unless you use the command-line switch, and if you *do* use that switch, it makes SEQ misbehave badly unless you think about it ahead of time.

You need to chown the whole seq install tree (/usr/local/share/showeq by default) to be owned by whatever user you're going to run SEQ as. So, for example:

# chown -R daemon:nobody /usr/local/share/showeq
# showeq --privsep-user=daemon

You only have to change the ownerships once, and of course, I'm just using daemon as an example. For convinience, you probably want to run it as your normal userid.

[Zaphod]

Technically you've been able to just run ShowEQ setuid for a long time now. If you make showeq setuid it will run as root only as long as is necessary to open the interface. Although you will have the same issues with needing to set the permissions and/or ownership of LOGDIR (typically '/usr/local/share/showeq').

Enjoy,
Zaphod (dohpaZ)

[karrde]

Originally posted by perlmonkey
You need to chown the whole seq install tree (/usr/local/share/showeq by default) to be owned by whatever user you're going to run SEQ as.

I'll add on that as part of what I was going to do when I did this myself, was create some seperation between a 'share/showeq' and '~/.showeq' to avoid problems like this. Perhaps doing things like map stacking between the disto version and personal versions, multi level filters (see another post I made about #include fuctionality in filters), etc, etc.

Saying that I haven't had a chance to try out your patch, perhaps this weekend.