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
> > 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 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
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
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 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
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, 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
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
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, 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" == 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: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> 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 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
15 matches
Mail list logo