public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Miell <nmiell@comcast.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: tridge@samba.org, Michael B Allen <mba2000@ioplex.com>,
	sfrench@samba.org, linux-ntfs-dev@lists.sourceforge.net,
	samba-technical@lists.samba.org, aia21@cantab.net,
	hirofumi@mail.parknet.co.jp,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: FAT, NTFS, CIFS and DOS attributes
Date: Mon, 03 Jan 2005 17:31:59 -0800	[thread overview]
Message-ID: <1104802319.3604.71.camel@localhost.localdomain> (raw)
In-Reply-To: <41D9E23A.4010608@zytor.com>

On Mon, 2005-01-03 at 16:24 -0800, H. Peter Anvin wrote:
> Right, it's the "design is broken so everything ends up in user.*". 

The design isn't broken, you're just missing an important detail of what
the system namespace entails:

xattrs in the system namespace have a format defined by the kernel and
(more importantly -- this is the important detail) modify kernel
behavior.

If the xattr namespace was flat, I would have no way of knowing whether
or not the kernel will set the Archived bit in fatattrs (or DosAttrib)
xattr when I write to a file that has that xattr or whether or not the
kernel will choose to enforce the ACL I store in the posix_acl_access
xattr.

With the system namespace, I can rely on the fact that xattrs in that
namespace actually have a meaning and are in sync with what the kernel
believes to be true about the file.

If I cannot rely on this to be true, than at best that's a bug and at
worst it's a gaping security hole. (NT ACLs can specify Allow and Deny,
if I create a NT ACL xattr that denies somebody access, the kernel damn
well better enforce it.)

Earlier you mentioned a desire to be able to backup the various pieces
of metadata that a filesystem exports via xattrs simply by copying the
files to another filesystem, and the fact that the destination
filesystem may not allow you to store the same attributes in the system
namespace as the source prevented you from being able to do this.

This is akin to complaining that you cannot make an accurate backup of
an ext3 filesystem simply by copying it's files to a vfat filesystem,
because vfat doesn't support the same notions of timestamps, ownership
or permissions that ext3 does.

Tools such as tar or cpio exist to store Unix files and their metadata
in a flat format, and they can be extended to understand the extra
metadata made available in Linux xattrs.

-- 
Nicholas Miell <nmiell@comcast.net>


  parent reply	other threads:[~2005-01-04  1:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 22:24 FAT, NTFS, CIFS and DOS attributes H. Peter Anvin
2005-01-03 23:26 ` Michael B Allen
2005-01-03 23:33   ` H. Peter Anvin
2005-01-03 23:48     ` Michael B Allen
2005-01-03 23:55       ` H. Peter Anvin
2005-01-04  0:18     ` tridge
2005-01-04  0:24       ` H. Peter Anvin
2005-01-04  0:39         ` tridge
2005-01-04  0:57           ` H. Peter Anvin
2005-01-04  1:12             ` tridge
2005-01-04  1:31         ` Nicholas Miell [this message]
2005-01-04  1:48           ` H. Peter Anvin
2005-01-04  2:05             ` Nicholas Miell
2005-01-04 22:24       ` [Linux-NTFS-Dev] " Szakacsits Szabolcs
2005-01-04  1:21   ` tridge
2005-01-04  1:30     ` H. Peter Anvin
2005-01-03 23:28 ` Nicholas Miell
2005-01-04  0:05 ` tridge
2005-01-04  0:30   ` H. Peter Anvin
2005-01-04  0:58     ` tridge
2005-01-04  1:14       ` H. Peter Anvin
2005-01-04  1:36         ` tridge
2005-01-04  1:50           ` H. Peter Anvin
2005-01-04  2:05             ` tridge
2005-01-04  2:09               ` H. Peter Anvin
2005-01-04  2:23               ` Kyle Moffett
2005-01-04  2:49                 ` tridge
2005-01-04  3:39                   ` Kyle Moffett
2005-01-04  3:56                     ` tridge
2005-01-04  4:50                       ` Kyle Moffett
2005-01-04  4:05     ` Michael B Allen
2005-01-04 10:34 ` Anton Altaparmakov
2005-01-04 11:08   ` Anton Altaparmakov
2005-01-04 22:18   ` Nicholas Miell
2005-01-04 23:04     ` Anton Altaparmakov
2005-01-05  0:48       ` Nicholas Miell
2005-01-05  1:12         ` Nicholas Miell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1104802319.3604.71.camel@localhost.localdomain \
    --to=nmiell@comcast.net \
    --cc=aia21@cantab.net \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=mba2000@ioplex.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    --cc=tridge@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox