From: NeilBrown <nfbrown@novell.com> To: Dave Chinner <david@fromorbit.com>, David Howells <dhowells@redhat.com> Cc: linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Date: Thu, 05 May 2016 10:09:49 +1000 [thread overview] Message-ID: <87shxxbc1e.fsf@notabene.neil.brown.name> (raw) In-Reply-To: <20160504225601.GZ26977@dastard> [-- Attachment #1: Type: text/plain, Size: 1738 bytes --] On Thu, May 05 2016, Dave Chinner wrote: > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: >> (4) File creation time (st_btime*), data version (st_version), inode >> generation number (st_gen). >> >> These will be returned if available whether the caller asked for them or >> not. The corresponding bits in st_mask will be set or cleared as >> appropriate to indicate a valid value. > > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. "security through obscurity". We have Kerberos working really nicely for NFS these days. Do we still care? What if the generation number were only made available to "root"? Would that allay your concerns? Would that still be useful? We already have name_to_handle_at(). Exposing the generation number could/should follow the same rules at that. Or maybe the exposure of each field should be guided by the filesystem, depending on (for example) whether it is used to provide uniqueness to the filehandle. > >> If the caller didn't ask for them, then they may be approximated. For >> example, NFS won't waste any time updating them from the server, unless >> as a byproduct of updating something requested. > > I would suggest that exposing them from the NFS server is something > we most definitely don't want to do because they are the only thing > that keeps remote users from guessing filehandles with ease.... Given that the NFS protocol does not define a "generation number" attribute, I think there is no risk for them being exposed from the NFS server ... except implicitly within the filehandle of course. NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <nfbrown-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> To: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Date: Thu, 05 May 2016 10:09:49 +1000 [thread overview] Message-ID: <87shxxbc1e.fsf@notabene.neil.brown.name> (raw) In-Reply-To: <20160504225601.GZ26977@dastard> [-- Attachment #1: Type: text/plain, Size: 1738 bytes --] On Thu, May 05 2016, Dave Chinner wrote: > On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote: >> (4) File creation time (st_btime*), data version (st_version), inode >> generation number (st_gen). >> >> These will be returned if available whether the caller asked for them or >> not. The corresponding bits in st_mask will be set or cleared as >> appropriate to indicate a valid value. > > IMO, exposing the inode generation number to anyone is a potential > security problem because they are used in file handles. "security through obscurity". We have Kerberos working really nicely for NFS these days. Do we still care? What if the generation number were only made available to "root"? Would that allay your concerns? Would that still be useful? We already have name_to_handle_at(). Exposing the generation number could/should follow the same rules at that. Or maybe the exposure of each field should be guided by the filesystem, depending on (for example) whether it is used to provide uniqueness to the filehandle. > >> If the caller didn't ask for them, then they may be approximated. For >> example, NFS won't waste any time updating them from the server, unless >> as a byproduct of updating something requested. > > I would suggest that exposing them from the NFS server is something > we most definitely don't want to do because they are the only thing > that keeps remote users from guessing filehandles with ease.... Given that the NFS protocol does not define a "generation number" attribute, I think there is no risk for them being exposed from the NFS server ... except implicitly within the filehandle of course. NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2016-05-05 0:10 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-29 12:57 [RFC][PATCH 0/6] Enhanced file stat system call David Howells 2016-04-29 12:57 ` [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells 2016-05-02 22:46 ` Andreas Dilger 2016-05-02 22:46 ` Andreas Dilger 2016-05-03 15:53 ` David Howells 2016-05-04 22:56 ` Dave Chinner 2016-05-05 0:09 ` NeilBrown [this message] 2016-05-05 0:09 ` NeilBrown 2016-05-05 19:48 ` Jeff Layton 2016-05-06 18:07 ` J. Bruce Fields 2016-05-06 18:07 ` J. Bruce Fields 2016-05-05 20:04 ` David Howells 2016-05-05 20:04 ` David Howells 2016-05-06 1:39 ` Dave Chinner 2016-05-06 1:39 ` Dave Chinner 2016-05-06 1:39 ` Dave Chinner 2016-05-06 18:29 ` J. Bruce Fields 2016-05-09 1:45 ` Dave Chinner 2016-05-09 2:46 ` J. Bruce Fields 2016-05-04 23:56 ` NeilBrown 2016-05-08 8:35 ` Christoph Hellwig 2016-05-08 8:35 ` Christoph Hellwig 2016-05-09 12:02 ` Jeff Layton 2016-05-09 12:02 ` Jeff Layton 2016-05-10 7:00 ` Christoph Hellwig 2016-05-10 7:00 ` Christoph Hellwig 2016-05-10 13:21 ` Jeff Layton 2016-05-10 13:21 ` Jeff Layton 2016-05-09 12:57 ` David Howells 2016-05-09 12:57 ` David Howells 2016-05-09 13:23 ` Trond Myklebust 2016-05-09 13:23 ` Trond Myklebust 2016-05-09 13:23 ` Trond Myklebust 2016-05-10 7:04 ` Christoph Hellwig 2016-05-10 8:25 ` David Howells 2016-05-12 9:11 ` Christoph Hellwig 2016-05-13 15:28 ` Arnd Bergmann 2016-05-13 15:28 ` Arnd Bergmann 2016-05-23 8:22 ` Christoph Hellwig 2016-05-23 9:33 ` David Howells 2016-05-18 10:55 ` David Howells 2016-05-09 13:00 ` David Howells 2016-05-09 13:00 ` David Howells 2016-05-09 13:38 ` David Howells 2016-05-10 7:08 ` Christoph Hellwig 2016-05-10 8:43 ` David Howells 2016-05-12 9:12 ` Christoph Hellwig 2016-05-09 13:40 ` David Howells 2016-04-29 12:57 ` [PATCH 2/6] statx: AFS: Return enhanced file attributes David Howells 2016-04-29 12:57 ` [PATCH 3/6] statx: Ext4: " David Howells 2016-05-02 22:48 ` Andreas Dilger 2016-05-03 20:24 ` David Howells 2016-05-03 20:24 ` David Howells 2016-05-08 8:38 ` Christoph Hellwig 2016-05-08 8:38 ` Christoph Hellwig 2016-04-29 12:58 ` [PATCH 4/6] statx: NFS: " David Howells 2016-05-02 22:48 ` Andreas Dilger 2016-04-29 12:58 ` [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use David Howells 2016-05-02 22:52 ` Andreas Dilger 2016-10-03 21:03 ` Steve French 2016-10-03 21:03 ` Steve French 2016-05-03 20:23 ` David Howells 2016-05-08 8:39 ` Christoph Hellwig 2016-05-08 8:39 ` Christoph Hellwig 2016-04-29 12:58 ` [PATCH 6/6] statx: CIFS: Return enhanced attributes David Howells 2016-04-30 21:05 ` [RFC][PATCH 0/6] Enhanced file stat system call Jeff Layton 2016-04-30 21:05 ` Jeff Layton 2016-05-04 13:46 ` Arnd Bergmann 2016-05-04 13:46 ` Arnd Bergmann 2016-05-05 22:54 ` Steve French 2016-05-06 2:00 ` Steve French 2016-05-09 13:09 ` Arnd Bergmann 2016-05-09 13:09 ` Arnd Bergmann 2016-05-13 14:28 ` Richard Sharpe 2016-05-13 14:28 ` Richard Sharpe 2016-05-13 15:08 ` Arnd Bergmann
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=87shxxbc1e.fsf@notabene.neil.brown.name \ --to=nfbrown@novell.com \ --cc=david@fromorbit.com \ --cc=dhowells@redhat.com \ --cc=linux-afs@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=samba-technical@lists.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.