For the benefit of packet sniffers and other things that only want
read-only access to /dev/bpf*, what do people think of adding a 'bpf'
group for those programs? This allows bpf devices to be read by
programs running with an effective gid of 'bpf' instead of the current
requirement for an effect
On Sat, Apr 20, 2002 at 03:39:14PM -0600, Lyndon Nerenberg wrote:
> For the benefit of packet sniffers and other things that only want
> read-only access to /dev/bpf*, what do people think of adding a 'bpf'
> group for those programs? This allows bpf devices to be read by
> programs running with
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> I do this a lot too on systems where it makes sense. But I'm
Crist> not sure I understand what you are asking to be done. Is it
Crist> asking too much of an administrator to do,
There are two ways to handle this. One
On Sat, Apr 20, 2002 at 04:02:13PM -0600, Lyndon Nerenberg wrote:
> > "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> I do this a lot too on systems where it makes sense. But I'm
> Crist> not sure I understand what you are asking to be done. Is it
> Crist> asking t
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> OK. Now you've really lost me. What do ports have to do with
Crist> this? Which ports? None of the sniffing programs I am aware
Crist> of use set{g,u}id bits. They rely on the permissions of the
Crist> user running
On Sat, Apr 20, 2002 at 04:27:18PM -0600, Lyndon Nerenberg wrote:
> > "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> OK. Now you've really lost me. What do ports have to do with
> Crist> this? Which ports? None of the sniffing programs I am aware
> Crist> of use
Crist J. Clark wrote:
> These are actually very different in that they are set{u,g}id commands
> (well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
> sniffing tools we've been discussing, and pretty much all of the ones
> I've used, tcpdump(1), snort(8), nmap(1), etc., are not.
On Sat, 20 Apr 2002, Craig Boston wrote:
> Since -current by default uses devfs, is there a standard way to make the
> ownership/permissions of device nodes "sticky" so that they persist across
> boots?
rc.devfs
--
"We have known freedom's price. We have shown freedom's power.
And in
On Sat, 20 Apr 2002, Craig Boston wrote:
> Since -current by default uses devfs, is there a standard way to make the
> ownership/permissions of device nodes "sticky" so that they persist across
> boots?
No.
Or should we just put the appropriate commands in rc.local ?
The problem has been moved
Bruce Evans wrote:
> On Sat, 20 Apr 2002, Craig Boston wrote:
> > Since -current by default uses devfs, is there a standard way to make the
> > ownership/permissions of device nodes "sticky" so that they persist across
> > boots?
>
> No.
>
> Or should we just put the appropriate commands in rc.l
On Sat, 20 Apr 2002, Doug Barton wrote:
> On Sat, 20 Apr 2002, Craig Boston wrote:
>
> > Since -current by default uses devfs, is there a standard way to make the
> > ownership/permissions of device nodes "sticky" so that they persist across
> > boots?
>
> rc.devfs
Unfortunately, this works p
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>> rc.devfs
>
>Unfortunately, this works poorly for cloned devices. At various meetings,
>there has been discussion of a devfsd and/or devd; that's probably the
>vehicle for doing that kind of administrative change. Unfortunately, it
>doesn
On Sun, 21 Apr 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Robe
> rt Watson writes:
>
> >> rc.devfs
> >
> >Unfortunately, this works poorly for cloned devices. At various meetings,
> >there has been discussion of a devfsd and/or devd; that's probably the
> >vehicle for doi
On Sat, 20 Apr 2002, Lyndon Nerenberg wrote:
> For the benefit of packet sniffers and other things that only want
> read-only access to /dev/bpf*, what do people think of adding a 'bpf'
> group for those programs? This allows bpf devices to be read by
> programs running with an effective gid of
> > For the benefit of packet sniffers and other things that only want
> > read-only access to /dev/bpf*, what do people think of adding a 'bpf'
> > group for those programs? This allows bpf devices to be read by
> > programs running with an effective gid of 'bpf' instead of the current
> > requi
On Mon, Apr 22, 2002 at 11:16:58AM -0700, Doug White wrote:
> On Sat, 20 Apr 2002, Lyndon Nerenberg wrote:
>
> > For the benefit of packet sniffers and other things that only want
> > read-only access to /dev/bpf*, what do people think of adding a 'bpf'
> > group for those programs? This allows
16 matches
Mail list logo