Linux-Fsdevel Archive on
help / color / mirror / Atom feed
From: Christian Schoenebeck <>
To: Dave Chinner <>
Cc: Matthew Wilcox <>,
	"Dr. David Alan Gilbert" <>,
	Greg Kurz <>,,,,,,,
Subject: file forks vs. xattr (was: xattr names for unprivileged stacking?)
Date: Mon, 17 Aug 2020 12:37:17 +0200	[thread overview]
Message-ID: <2859814.QYyEAd97eH@silver> (raw)
In-Reply-To: <20200817002930.GB28218@dread.disaster.area>

On Montag, 17. August 2020 00:56:20 CEST Dave Chinner wrote:
> > That's yet another question: should xattrs and forks share the same data-
> > and namespace, or rather be orthogonal to each other.
> Completely orthogonal. Alternate data streams are not xattrs, and
> xattrs are not ADS....

Agreed. Their key features (atomic small data vs. non-atomic large data) and 
their typical uses cases are probably too different for trying to stitch them 
somehow in an erroneous way into a shared space. Plus it would actually be 
beneficial if forks had their own xattrs.

On Montag, 17. August 2020 02:29:30 CEST Dave Chinner wrote:
> I'd stop calling these "forks" already, too. The user wants
> "alternate data streams", while a "resource fork" is an internal
> filesystem implementation detail used to provide ADS
> functionality...

The common terminology can certainly still be argued. I understand that from 
fs implementation perspective "fork" is probably ambiguous. But from public 
API (i.e. user space side) perspective the term "fork" does make sense, and so 
far I have not seen a better general term for this. Plus the ambiguous aspects 
on fs side are not exposed to the public side.

The term "alternate data stream" suggests that this is just about the raw data 
stream, but that's probably not what this feature will end up being limited 
to. E.g. I think they will have their own permissions on the long term (see 
below). Plus the term ADS is ATM somewhat sticky to the Microsoft universe.

> IOWs, with a filesystem inode fork implementation like this for ADS,
> all we really need is for the VFS to pass a magic command to
> ->lookup() to tell us to use the ADS namespace attached to the inode
> rather than use the primary inode type/state to perform the
> operation.

IMO starting with a minimalistic approach, in a way Solaris developers 
originally introduced forks, would IMO make sense for Linux as well:

- Adding a new option O_FORK to fcntl.h (Solaris uses O_XATTR, not a good
  idea for Linux though for reasons discussed).

- (Mis)using existing APIs for accessing forks (i.e. *at() functions):

	/* open fork 'foo' of file 'sheet.pdf' */

	int fdfile = open("sheet.pdf", O_PATH);
	int fdfork = openat(fdfile, "foo", O_FORK);
	/* continue with regular file I/O on fdfork now ... */


	/* list all forks of file 'sheet.pdf' */

	int fdfile = open("sheet.pdf", O_PATH);
	int fdlist = openat(fdfile, ".", O_RDONLY|O_FORK);
	DIR* dir = fdopendir(fdlist);
	struct dirent* dent;
	while ((dent = readdir(dir)) {

- Permissions and ownership: Same as the file for simplicity as starting 
  point for the first version (see below).

- No subforks as starting point, and hence path separator '/' inside fork 
  names would be prohibited initially to avoid future clashes.

> Hence all the ADS support infrastructure is essentially dentry cache
> infrastructure allowing a dentry to be both a file and directory,
> and providing the pathname resolution that recognises an ADS
> redirection. Name that however you want - we've got to do an on-disk
> format change to support ADS, so we can tell the VFS we support ADS
> or not. And we have no cares about existing names in the filesystem
> conflicting with the ADS pathname identifier because it's a mkfs
> time decision. Given that special flags are needed for the openat()
> call to resolve an ADS (e.g. O_ALT), we know if we should parse the
> ADS identifier as an ADS the moment it is seen...

So you think there should be a built-in full qualified path name resolution to 
forks right from the start? E.g. like on Windows "C:\some\where\sheet.pdf:foo" 
-> fork "foo" of file "sheet.pdf"?

> > I don't understand why a fork would be permitted to have its own
> > permissions.  That makes no sense.  Silly Solaris.
> I can't think of a reason why, either, but the above implementation
> for XFS would support it if the presentation layer allows it... :)

I would definitely not add this right from the start of course, but on the 
long term it actually does make senses for them having their own permissions, 
simply because there are already applications for that:

E.g. on some systems forks are used to tag files for security relevant issues, 
for instance where the file originated from (a trusted vs. untrusted source). 
If it was a untrusted source, the user is made aware about this circumstance 
by the system when attempting to open the file. In this use case the fork 
would probably have more restrictive permissions than the actual file.

OTOH forks are used to extend existing files in non-obtrusive way. Say you 
have some sort of (e.g. huge) master file, and a team works on that file. Then 
the individual people would attach their changes solely as forks to the master 
file with their ownership, probably even with complex ACLs, to prevent certain 
users from touching (or even reading) other ones changes. In this use case the 
master file might be readonly for most people, while the individual forks 
being anywhere between more permissive or more restrictive.

Best regards,
Christian Schoenebeck

  reply	other threads:[~2020-08-17 10:37 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 10:55 xattr names for unprivileged stacking? Dr. David Alan Gilbert
2020-07-28 13:08 ` Greg Kurz
2020-07-28 13:55   ` Christian Schoenebeck
2020-08-04 11:28     ` Dr. David Alan Gilbert
2020-08-04 13:51       ` Christian Schoenebeck
2020-08-12 11:18         ` Dr. David Alan Gilbert
2020-08-12 13:34           ` Christian Schoenebeck
2020-08-12 14:33             ` Dr. David Alan Gilbert
2020-08-13  9:01               ` Christian Schoenebeck
2020-08-16 22:56                 ` Dave Chinner
2020-08-16 23:09                   ` Matthew Wilcox
2020-08-17  0:29                     ` Dave Chinner
2020-08-17 10:37                       ` Christian Schoenebeck [this message]
2020-08-23 23:40                         ` file forks vs. xattr (was: xattr names for unprivileged stacking?) Dave Chinner
2020-08-24 15:30                           ` Christian Schoenebeck
2020-08-24 20:01                             ` Miklos Szeredi
2020-08-24 21:26                             ` Frank van der Linden
2020-08-24 22:29                             ` Theodore Y. Ts'o
2020-08-25 15:12                               ` Christian Schoenebeck
2020-08-25 15:32                                 ` Miklos Szeredi
2020-08-27 12:02                                   ` Christian Schoenebeck
2020-08-27 12:25                                     ` Matthew Wilcox
2020-08-27 13:48                                       ` Christian Schoenebeck
2020-08-27 14:01                                         ` Matthew Wilcox
2020-08-27 14:23                                           ` Christian Schoenebeck
2020-08-27 14:25                                             ` Matthew Wilcox
2020-08-27 14:44                                             ` Al Viro
2020-08-27 16:29                                               ` Dr. David Alan Gilbert
2020-08-27 16:35                                                 ` Matthew Wilcox
2020-08-28  9:11                                                 ` Christian Schoenebeck
2020-08-28 14:46                                                   ` Theodore Y. Ts'o
2020-08-27 15:22                       ` xattr names for unprivileged stacking? Matthew Wilcox
2020-08-27 22:24                         ` Dave Chinner
2020-08-29 16:07                           ` Matthew Wilcox
2020-08-29 16:13                             ` Al Viro
2020-08-29 17:51                               ` Miklos Szeredi
2020-08-29 18:04                                 ` Al Viro
2020-08-29 18:22                                   ` Christian Schoenebeck
2020-08-29 19:13                                   ` Miklos Szeredi
2020-08-29 19:25                                     ` Al Viro
2020-08-30 19:05                                       ` Miklos Szeredi
2020-08-30 19:10                                         ` Matthew Wilcox
2020-08-31  7:34                                           ` Miklos Szeredi
2020-08-31 11:37                                             ` Matthew Wilcox
2020-08-31 11:51                                               ` Miklos Szeredi
2020-08-31 13:23                                                 ` Matthew Wilcox
2020-08-31 14:21                                                   ` Miklos Szeredi
2020-08-31 14:25                                                   ` Theodore Y. Ts'o
2020-08-31 14:45                                                     ` Matthew Wilcox
2020-08-31 14:49                                                       ` Miklos Szeredi
2020-09-01  3:34                                                     ` Dave Chinner
2020-09-01 14:52                                                       ` Theodore Y. Ts'o
2020-09-01 15:14                                                         ` Theodore Y. Ts'o
2020-09-02  5:19                                                           ` Dave Chinner
2020-08-31 18:02                                                   ` Andreas Dilger
2020-09-01  3:48                                                     ` Dave Chinner
2020-08-29 19:17                               ` Matthew Wilcox
2020-08-29 19:40                                 ` Al Viro
2020-08-29 20:12                                   ` Matthew Wilcox
2020-08-31 14:23                                     ` Theodore Y. Ts'o
2020-08-31 14:40                                       ` Matthew Wilcox
2020-08-31 16:11                                       ` Christian Schoenebeck

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:

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

  git send-email \
    --in-reply-to=2859814.QYyEAd97eH@silver \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: file forks vs. xattr (was: xattr names for unprivileged stacking?)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).