From owner-freebsd-current  Sat Feb 10 16:52:48 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA25607
          for current-outgoing; Sat, 10 Feb 1996 16:52:48 -0800 (PST)
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA25594
          for <current@FreeBSD.ORG>; Sat, 10 Feb 1996 16:52:44 -0800 (PST)
Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id QAA05129; Sat, 10 Feb 1996 16:52:04 -0800
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199602110052.QAA05129@ref.tfs.com>
Subject: Re: FS PATCHES: THE NEXT GENERATION
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Sat, 10 Feb 1996 16:52:03 -0800 (PST)
Cc: terry@lambert.org, KentH@HNS.St-Louis.Mo.US, current@FreeBSD.ORG
In-Reply-To: <29143.823998441@time.cdrom.com> from "Jordan K. Hubbard" at Feb 10, 96 04:27:21 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-current@FreeBSD.ORG
Precedence: bulk

> 
I put it to you that security of devices is such an important thing
that you don't want persistance of device ownerships
I think that device ownerships should be set upaccording
to a STATED POLICY on the matter.
A hacker who manages to change the ownership od a device
should not find his change still in place after a reboot.

All automatic methods I can think of do not differntiate between
a malicious or legitimate cahnging of permissions information.

A POLICY method can take into account new devices
where persistance methods can not handle a device that does not
yet exist.
I think that having entries for devices not yet present is one
of the things I'm trying to get away from...

batteries nearly dead.. going offline soon.

julian


> > I see no philosophical difference from one administrative override
> > that modifies the default kernel and another that modifies the
> > same file, but operates on different data.
> 
> Neither do I, but no proposal so far has covered a mechanism which
> would make the maintainance of this data automatic.  In the case of
> dset, it's one line which *we* added, and most users don't even _know_
> or care about dset, they just know their UserConfig changes are
> automagically saved somehow, which is how it should be.
> 
> Implement a mechanism as user-transparent as dset for /dev persistance
> and I'll more than happily shut up about this.
> 
> 						Jordan
>