Re: Ext3 filesystem info?

Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Tue, 28 Sep 1999 08:56:24 -0500 (CDT)


> From bear@coyotesong.com Mon Sep 27 23:00:52 1999
> > From: Bear Giles <bear@coyotesong.com>
> > ...
> > >Finally, once that's stable we can decide how to handle non-native ACLs
> > >(e.g., those that require 128-bit UUIDs).
> >
> > The problem is that selecting a very minimalist implementation too early
> > can force a complete redesign replacement later.
>
> Granted, but it seemed that the "what about NTFS" thread was getting
> out of control. Why would you ever read a NTFS disk on a Linux system
> unless you're dual booting, and why would you care about ACLs in that
> case? (Security 101: you can't guarantee anything if you don't have
> physical control of the system. It would be nice if we honored NTFS
> ACLs, but we shouldn't be trusting NT applications to honor *ours*.)

NT doesn't - I haven't seen any NT system mount filesystems that MS didn't
develop. This does NOT refer to samba - that makes OUR file system look like
THEIRS, and yes it would be good to support NT ACLs in that case.

> Once you get that out of the way it seems that everything falls into
> one of three cases: it's either a local Linux-like disk or it's a
> remote/distributed disk. Remote/distributed file systems will either
> have ownership and permissions which can be clearly mapped to ours, or
> they won't. It's only the last case where we will have problems, and
> we would have problems in any case. (E.g., do we force all file systems
> to carry an extra 2k of code to support an obscure FS's semantics?)

1. The distributed file system may come from a Linux server - It would then
be a Good Thing to support any ACLs on the distributed file system
(NFS/Coda? If NFS then the underlying file system may have ACLs)
2. The outline I provided does not "force" any ACL support. If it isn't
supported then the value ENOSYS should be returned to indicate
that it doesn't exist.

I tried to lay out a proposal that doesn't impose any constraints on the
ACL implementation in the kernel. The filesystem layer should make that
determination.

I also didn't mandate an external daemon to perform translation services, but
one could be used. The application library/editor could communicate with
a daemon for translations, that would be up to the library/editor.

> Bear Giles
> bgiles@coyotesong.com
>
> (P.S., I know that you could put NTFS on removable media, so the
> "dual boot" argument isn't watertight. But the "physical control
> of the media" problem remains - nobody using ACLs should depend on
> those ACLs being honored once the media leaves their control.)

Yup. Didn't mean to imply that removable media was any different - but
consider:
20GB IDE/SCSI removable disk sleds. IF the facility provides for
secure storage then the ACLs (and MAC labels too) are also secure.

We have labeled removable media here (file migration to 50GB tapes) and in
a secure facility. Labels can still be trusted since users cannot get their
hands on it. 27TB of data cannot all be stored on non-removable disks (at
least not yet).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/