Sorry, this is somewhat late.
On Wed, 6 Oct 1999, Wilfredo Sanchez wrote:
| Have you given consideration to systems where the user/group
database is
| kept for (possibly a large) number of computers in a centralised
manner by
| say hesiod or nys (nis+). It would be nice if there was
[.]
Revisiting security now...
A provision for public-key encryption of the data held on the disk (as
well as the id itself) would be useful. Just encrypting the ID alone
would not be useful.
The distinction would then shift away from whether the media is
Kris Kennaway [EMAIL PROTECTED] writes:
Make uids randomly assigned. This solves the problem of collision between
uids on an introduced medium and the ones on the local system by making it
statistical (if the uid space is large enough). In order to manage this
among multiple machines, you'd
Wilfredo Sanchez wrote:
| While it is certainly true that a person could eventually get
physical
| access into the machine, it is a significantly more difficult
task and
| therefore a significant distinction still exists between the
data stored
| on the hard drive and
:On 6 Oct, Wilfredo Sanchez wrote:
: | I would rather brand the filesystem with the ID of the host. The
: | starting situation is an "unmarked" filesystem. If a host detects the
: | mounting of an "unmarked" filesystem, it will brand it with it's ID. If
: | it detects a filesystem that has an
Matthew Dillon wrote
Revisiting security now...
A provision for public-key encryption of the data held on the disk (as
well as the id itself) would be useful. Just encrypting the ID alone
would not be useful.
The distinction would then shift away from whether the
| Please, don't give me this crap. "Removable media" is a very
| well-defined terminology.
Only in screw-your-device-into-the-machine land.
We're have to consider hot-swappable devices, including hard disks
and floppies and video cameras and new-uber-whatzit-media.
The admin has
[.]
As I pointed out, the distinction is one of intent on the part of
the admin.
Absolutely.
--
Daniel C. Sobral (8-DCS)
[.]
--
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
http://www.Awfulhak.org [EMAIL PROTECTED]
Here's a passing thought I had which may be relevant.
Make uids randomly assigned. This solves the problem of collision between
uids on an introduced medium and the ones on the local system by making it
statistical (if the uid space is large enough). In order to manage this
among multiple
Pat Dirks wrote:
ADOPTING "FOREIGN" FILESYSTEMS
When a new, never before seen disk is first mounted in the system it's
treated as "foreign". This can be changed (with "root" permissions) to
make the filesystem "local". The filesystem's ID is added to the list of
local filesystems and
At 4:20 AM -0700 10/6/99, Daniel C. Sobral wrote:
It is no worse than uid/gid problems with NFS.
Umm, what is this, FreeBSD-Humor? Thanks for the laugh, and remember, it's
just a nasty old rumor that NFS stands for "No File Security" :-/
--
Conrad Minshall ... [EMAIL PROTECTED] ... 408
Conrad Minshall wrote:
At 4:20 AM -0700 10/6/99, Daniel C. Sobral wrote:
It is no worse than uid/gid problems with NFS.
Umm, what is this, FreeBSD-Humor? Thanks for the laugh, and remember, it's
just a nasty old rumor that NFS stands for "No File Security" :-/
This is no joke. When
On Tue, 5 Oct 1999, Pat Dirks wrote:
Hi,
I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group.
We've been struggling with the question of how best to handle permissions
on disks that are moved between systems for Mac OS X and Mac OS X Server:
the problem is that
On 5 Oct, Pat Dirks wrote:
Sorry if I'm talking nonsense or if somebody else already pointed this
out, i usually just lurk around this list, but if I'm right I think it
is of sufficient significance...
ADOPTING "FOREIGN" FILESYSTEMS
When a new, never before seen disk is first mounted in
On Wed, 6 Oct 1999, Darren R. Davis wrote:
Narvi wrote:
[snip]
Have you given consideration to systems where the user/group database is
kept for (possibly a large) number of computers in a centralised manner by
say hesiod or nys (nis+). It would be nice if there was an easy
On Wed, Oct 06, 1999 at 11:18:59PM +0900, Daniel C. Sobral wrote:
One would better assume that files available over NFS will be read
by anyone who wants, and, likewise, that files available on
removable media will be read by anyone who wants. That side of the
problem does not belong to this
Alban Hertroys wrote:
On 5 Oct, Pat Dirks wrote:
Sorry if I'm talking nonsense or if somebody else already pointed this
out, i usually just lurk around this list, but if I'm right I think it
is of sufficient significance...
ADOPTING "FOREIGN" FILESYSTEMS
When a new, never before
:Show me a disk that's _not_ removable. By your logic we would have _no_
:sguid/sgid binaries _ever._
:
:Physical access to a machine is always a security risk. Why would you
:treat easily-removable media any differently to slightly-harder-to-remove
:media? You still need to break into the vault
Narvi wrote:
On Tue, 5 Oct 1999, Pat Dirks wrote:
Hi,
I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group.
We've been struggling with the question of how best to handle permissions
on disks that are moved between systems for Mac OS X and Mac OS X Server:
the
Joe Abley wrote:
On Wed, Oct 06, 1999 at 11:18:59PM +0900, Daniel C. Sobral wrote:
One would better assume that files available over NFS will be read
by anyone who wants, and, likewise, that files available on
removable media will be read by anyone who wants. That side of the
problem
[.]
Instead we decided to leave all name - ID mapping systems unchanged and
rely on a distinction between "local" filesystems whose permissions
information should be used and a "foreign" filesystem mode where owner
and group IDs are ignored.
[.]
I think the owner and group of the
| I think the owner and group of the person that mounted the filesystem
| should be assigned to all files on that filesystem in FOREIGN mode.
| -u and -g switches should be permitted to modify these, the -u being
| restricted to root and the -g restricted to root or one of the groups
|
ADOPTING "FOREIGN" FILESYSTEMS
When a new, never before seen disk is first mounted in the system it's
treated as "foreign". This can be changed (with "root" permissions) to
make the filesystem "local". The filesystem's ID is added to the list of
local filesystems and forever after when
On 5 Oct, Pat Dirks wrote:
Sorry if I'm talking nonsense or if somebody else already pointed this
out, i usually just lurk around this list, but if I'm right I think it
is of sufficient significance...
ADOPTING "FOREIGN" FILESYSTEMS
When a new, never before seen disk is first mounted in
On Thu, 7 Oct 1999, Alban Hertroys wrote:
On 6 Oct, Wilfredo Sanchez wrote:
| I would rather brand the filesystem with the ID of the host. The
| starting situation is an "unmarked" filesystem. If a host detects the
| mounting of an "unmarked" filesystem, it will brand it with it's ID.
Date: Tue, 5 Oct 1999 14:19:22 -0700
From: Pat Dirks [EMAIL PROTECTED]
[Lots of interesting, useful stuff elided -- dhw]
ADOPTING "FOREIGN" FILESYSTEMS
...
Note that one interesting option might be to provide a one-time-only
"adoption" which has no permanent effect; when the disk is
On Tue, 5 Oct 1999, Pat Dirks wrote:
Hi,
I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group.
We've been struggling with the question of how best to handle permissions
on disks that are moved between systems for Mac OS X and Mac OS X Server:
the problem is that
On Tue, 5 Oct 1999, Pat Dirks wrote:
as "local". As part of this "adoption" process the users is prompted to
choose one of two ways to handle the existing permissions on the disk:
* Retain them as-is (useful for cases where you have external
reasons to believe
the numeric
28 matches
Mail list logo
