On Mon, Dec 16, 2002 at 12:26:01PM -0800, Guy Harris wrote: > My inclination would be to do the "try read-write and, if that fails > with EACCESS, try read-only" - that might not do the right thing if some > BPF devices are read-write by the user trying to open them and some are > read-only, but all the BPF devices should, if accessible by a user at > all, be accessible with the same permissions (I guess somebody might > want to make some of them accessible only be root to reserve them for > use by root).
Unfortunately, that means that an application that has to write to the BPF device (or whatever) won't know that it's not permitted to do so until it tries to do so. A "pcap_open_live_ex()" API could have "promisc" replaced by "flags", which could include a capture-only vs. send-only vs. capture-and-send flag, a promiscuous flag, and perhaps other flags such as a "does the pcap_t need to work in a child process?" flag (if set, libpcap might avoid using a memory-mapped capture mechanism, as the claim is that a reason not to automatically use such a mechanism is that applications of that sort don't work). - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
