Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, Al Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Greg Kurz <groug@kaod.org>,
	linux-fsdevel@vger.kernel.org, stefanha@redhat.com,
	mszeredi@redhat.com, vgoyal@redhat.com, gscrivan@redhat.com,
	dwalsh@redhat.com, chirantan@chromium.org
Subject: Re: xattr names for unprivileged stacking?
Date: Mon, 31 Aug 2020 18:11:17 +0200	[thread overview]
Message-ID: <3192737.RVN0C98cj1@silver> (raw)
In-Reply-To: <20200831142312.GB4267@mit.edu>

On Sonntag, 30. August 2020 21:05:40 CEST Miklos Szeredi wrote:
> On Sat, Aug 29, 2020 at 9:25 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Sat, Aug 29, 2020 at 09:13:24PM +0200, Miklos Szeredi wrote:
> > > > d_path() is the least of the problems, actually.  Directory tree
> > > > structure on those, OTOH, is a serious problem.  If you want to have
> > > > getdents(2) on that shite, you want an opened descriptor that looks
> > > > like a directory.  And _that_ opens a large can of worms.  Because
> > > > now you have fchdir(2) to cope with, lookups going through
> > > > /proc/self/fd/<n>/..., etc., etc.
> > > 
> > > Seriously, nobody wants fchdir().  And getdents() does not imply
> > > fchdir().
> > 
> > Yes, it does.  If it's a directory, fchdir(2) gets to deal with it.
> > If it's not, no getdents(2).  Unless you special-case the damn thing in
> > said fchdir(2).
> 
> Huh?  f_op->iterate() needed for getdents(2) and i_op->lookup() needed
> for fchdir(2).
> 
> Yes, open(..., O_ALT) would be special.  Let's call it open_alt(2) to
> avoid confusion with normal open on a normal filesystem.   No special
> casing anywhere at all.   It's a completely new interface that returns
> a file which either has ->read/write() or ->iterate() and which points
> to an inode with empty i_ops.

Wouldn't that be overkill to introduce a new syscall just for that?
My {disclaimer: quick & naive} approach would be sticking a new flag 
S_ALT_WHATEVER onto i_flags maybe? And hard code denial in 
inode_permission(MAY_EXEC) if that S_ALT_WHATEVER flag is present? Then you 
can getdents() but not fchdir() into it, if I am not missing something.

On Montag, 31. August 2020 09:34:20 CEST Miklos Szeredi wrote:
> On Sun, Aug 30, 2020 at 9:10 PM Matthew Wilcox <willy@infradead.org> wrote:
> > On Sun, Aug 30, 2020 at 09:05:40PM +0200, Miklos Szeredi wrote:
> > > Yes, open(..., O_ALT) would be special.  Let's call it open_alt(2) to
> > > avoid confusion with normal open on a normal filesystem.   No special
> > > casing anywhere at all.   It's a completely new interface that returns
> > > a file which either has ->read/write() or ->iterate() and which points
> > > to an inode with empty i_ops.
> > 
> > I think fiemap() should be allowed on a stream.  After all, these extents
> > do exist.  But I'm opposed to allowing getdents(); it'll only encourage
> > people to think they can have non-files as streams.
> 
> Call it whatever you want.  I think getdents (without lseek!!!)  is a
> fine interface for enumeration.
> 
> Also let me stress again, that this ALT thing is not just about
> streams, but a generic interface for getting OOB/meta/whatever data
> for a given inode/path.  Hence it must have a depth of at least 2, but
> limiting it to 2 would again be shortsighted.

Al, feeling about these two issues?

On Montag, 31. August 2020 16:23:12 CEST Theodore Y. Ts'o wrote:
> On Sat, Aug 29, 2020 at 09:12:45PM +0100, Matthew Wilcox wrote:
> > > 	3) what happens to it if that underlying file is unlinked?
> > 
> > Unlinking a file necessarily unlinks all the streams.  So the file
> > remains in existance until all fds on it are closed, including all
> > the streams.
> 
> That's a bad idea, because if the fds are closed silently, then they
> can be reused; and then if the userspace library tries to write to
> what it *thinks* is an ADS file, not knowing that the application has
> unlinked and closed the ADS file, user file data would be lost.

Why would that be bad with ADS while it is Ok with regular files right now?

Best regards,
Christian Schoenebeck



      parent reply	other threads:[~2020-08-31 16:11 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 10:55 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                       ` file forks vs. xattr (was: xattr names for unprivileged stacking?) Christian Schoenebeck
2020-08-23 23:40                         ` 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 [this message]

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=3192737.RVN0C98cj1@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=chirantan@chromium.org \
    --cc=david@fromorbit.com \
    --cc=dgilbert@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=groug@kaod.org \
    --cc=gscrivan@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vgoyal@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: xattr names for unprivileged stacking?' \
    /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

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).