From: tridge@samba.org
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: 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: Tue, 4 Jan 2005 12:36:42 +1100 [thread overview]
Message-ID: <16857.62250.259275.305392@samba.org> (raw)
In-Reply-To: <41D9EDF6.1060600@zytor.com>
> More or less what you seem to want is an ioctl() that takes a mask of
> what to write, similar to the way notify_change() works inside the
> kernel. This is a legitimate API, but it requires knowledge of the
> internals, and isn't setxattr(). The big thing here is the need for a mask.
That API would make sense, but I didn't really expect the kernel to
provide it. What I expected to happen was for Samba4 to use the xattr
blobs like it does now, hopefully for Wine to learn to interpret those
same blobs, for backup/restore apps to learn to backup/restore them
(as blobs, with no interpretation) and for the proposed Samba LSM
module to do the dirty work of interpreting the contents of these
blobs in-kernel to provide raceless windows file serving.
The LSM module would then expose a richer API to a user space library
via some yet to be determined mechanism (netlink? ioctl? sysfs? proc?
dunno yet). That API would include the ability to tell the LSM module
what "nt token" (the windows equivalent of euid, egid and
supplementary groups) to use for operations, thus allowing the module
to correctly interpret the NT ACLs for read/write access to each of
these attributes. The module would also cache the xattr blob contents,
in unpacked form, to allow access decisions to be made very fast.
The whole design was based on the idea that proposing anything more
intrusive would (quite rightly) get smacked down as "this is not NT,
go away".
> Also see my previous note about endianness of structures carried
> from place to place.
I specifically chose NDR (and specifically little-endian NDR) as it
solves the endianness and 32/64 bit problems. You can take these blobs
and put them on any platform and they will be interpreted the same.
We also have a mechanism (an external tdb) for storing these xattrs on
filesystems that have no xattr support. That allows Samba4 to be fully
functional on any platform, but just much more efficient and scalable
on platforms that do have xattrs.
Cheers, Tridge
next prev parent reply other threads:[~2005-01-04 1:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-03 22:24 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
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 [this message]
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=16857.62250.259275.305392@samba.org \
--to=tridge@samba.org \
--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=samba-technical@lists.samba.org \
--cc=sfrench@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
Powered by JetHome