On Mon, Feb 03, 2014 at 10:31:27PM +, Al Viro wrote:
>
> > And the fact is, filesystems with hardlinks and path-name-based
> > operations do exist. cifs with the unix extensions is one of them.
>
> Pox on Tridge...
Actually you have to blame me for that. Tridge always
*HATED* the UNIX extens
On Tue, Feb 4, 2014 at 3:33 AM, Steven Whitehouse wrote:
>
> The other question that I have relating to that side of things, is why
> security_inode_permission() is called from __inode_permission() rather
> than from generic_permission() ? Maybe there is a good reason, but I
> can't immediately se
On Tue, Feb 04, 2014 at 11:33:35AM +, Steven Whitehouse wrote:
> To diverge from that topic for a moment, this thread has also brought
> together some discussion on another issue which I've been pondering
> recently that of whether the inode operations for get/set_xattr
> should take a dent
On Mon, 2014-02-03 at 22:40 +, Al Viro wrote:
> > >> +static int gfs2_vfs_permission(struct dentry *dentry, struct inode
> > >> *inode, int mask)
> > >> +{
> > >> + return gfs2_permission(inode, mask);
> > >> +}
> > >
> > > Er... You do realize that callers of gfs2_permission() tend to ha
On Mon, Feb 3, 2014 at 2:40 PM, Al Viro wrote:
>
> Umm... Point, but that actually means that we get an extra pitfall for
> filesystem writers here. foo_permission() passes dentry (now that it
> has one) to foo_wank_a_lot(), with the latter using dentry->d_inode at
> some point...
I agree.
The
On Mon, Feb 03, 2014 at 02:12:00PM -0800, Linus Torvalds wrote:
> >> -int afs_permission(struct inode *inode, int mask)
> >> +int afs_permission(struct dentry *dentry, struct inode *inode, int mask)
> >
> > Oh, _lovely_. So not only do we pass dentry, the arguments are redundant
> > as well.
>
>
On Mon, Feb 03, 2014 at 01:44:22PM -0800, Linus Torvalds wrote:
> On Mon, Feb 3, 2014 at 1:39 PM, Al Viro wrote:
> >
> > If we really have hardlinks, the result of permission check would better
> > be a function of inode itself - as in, "if it gives different results
> > for two pathnames reachabl
On Mon, Feb 3, 2014 at 1:59 PM, Al Viro wrote:
> On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
>
>> - err = vfs_mkdir(path.dentry->d_inode, dentry, mode);
>> + err = vfs_mkdir(path.dentry, dentry, mode);
>
> Pointless - path.dentry == dentry->d_parent anyway.
Heh. It's n
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
> - err = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> + err = vfs_mkdir(path.dentry, dentry, mode);
Pointless - path.dentry == dentry->d_parent anyway.
> - err = vfs_mknod(path.dentry->d_inode, dentry, mode, dev->d
On Mon, Feb 3, 2014 at 1:39 PM, Al Viro wrote:
>
> If we really have hardlinks, the result of permission check would better
> be a function of inode itself - as in, "if it gives different results
> for two pathnames reachable for the same user, we have a bug".
No. You're wrong.
EVEN ON A UNIX FI
On Mon, Feb 03, 2014 at 01:37:03PM -0800, Linus Torvalds wrote:
> On Mon, Feb 3, 2014 at 1:31 PM, Al Viro wrote:
> >
> > Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
> > is just fine.
>
> Hmm? I'm pretty sure cifs can actually have hardlinks.
*UGH*
How the hell does
On Mon, Feb 03, 2014 at 09:39:26PM +, Al Viro wrote:
> Which fs are you talking about? For 9P it *is* a function of inode alone.
> For CIFS there's no wrong dentry to pick - it doesn't have links to start
> with.
Except that apparently it does ;-/ Bugger...
--
To unsubscribe from this list:
On Mon, Feb 03, 2014 at 01:31:19PM -0800, Linus Torvalds wrote:
> If the protocol is path-based (and it happens, and it's actually the
> *correct* thing to do for a network filesystem, rather than the
> idiotic "file handle" crap that tries to emulate the unix inode
> semantics in the protocol), t
On Mon, Feb 3, 2014 at 1:31 PM, Al Viro wrote:
>
> Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
> is just fine.
Hmm? I'm pretty sure cifs can actually have hardlinks.
Linus
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the b
On Mon, Feb 03, 2014 at 09:31:53PM +, Al Viro wrote:
> Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
> is just fine.
It does have hardlinks, look at cifs_hardlink and functions called from
it.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel"
On Mon, Feb 03, 2014 at 01:24:47PM -0800, Christoph Hellwig wrote:
> On Mon, Feb 03, 2014 at 09:19:55PM +, Al Viro wrote:
> > Result *is* a function of inode alone; the problem with 9P is that we
> > are caching FIDs in the wrong place.
>
> I don't think that's true for CIFS unfortunately, whi
On Mon, Feb 3, 2014 at 1:19 PM, Al Viro wrote:
>
> Please, don't do that. Half of that is pointless (e.g. what you are
> doing with vfs_rmdir() - if anything, we could get rid of the first
> argument completely, it's always victim->d_parent->d_inode and we are
> holding enough locks for that to b
On Mon, Feb 03, 2014 at 09:19:55PM +, Al Viro wrote:
> Result *is* a function of inode alone; the problem with 9P is that we
> are caching FIDs in the wrong place.
I don't think that's true for CIFS unfortunately, which is path based.
--
To unsubscribe from this list: send the line "unsubscri
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
> Now, to be honest, pushing it down one more level (to
> generic_permission()) will actually start causing some trouble. In
> particular, gfs2_permission() fundamentally does not have a dentry for
> several of the callers.
Looking ov
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
> What do you think? I guess this patch could be split up into two: one
> that does the "vfs_xyz()" helper functions, and another that does the
> inode_permission() change. I tied them together mainly because I
> started with the inod
On Mon, Feb 03, 2014 at 02:29:43AM -0800, Christoph Hellwig wrote:
> On Thu, Jan 30, 2014 at 02:01:38PM -0800, Linus Torvalds wrote:
> > In the end, all the original call-sites should have a dentry, and none
> > of this is "fundamental". But you're right, it looks like an absolute
> > nightmare to
On Thu, Jan 30, 2014 at 02:01:38PM -0800, Linus Torvalds wrote:
> In the end, all the original call-sites should have a dentry, and none
> of this is "fundamental". But you're right, it looks like an absolute
> nightmare to add the dentry pointer through the whole chain. Damn.
>
> So I'm not thril
On Thu, 30 Jan 2014, Linus Torvalds wrote:
> On Wed, Jan 29, 2014 at 11:54 PM, Christoph Hellwig
> wrote:
> >
> > For ->set_acl that's fairly easily doable and I actually had a version
> > doing that to be able to convert 9p. But for ->get_acl the path walking
> > caller didn't seem easily feasi
On Wed, Jan 29, 2014 at 11:54 PM, Christoph Hellwig wrote:
>
> For ->set_acl that's fairly easily doable and I actually had a version
> doing that to be able to convert 9p. But for ->get_acl the path walking
> caller didn't seem easily feasible. ->get_acl actually is an invention
> of yours, so
On Wed, Jan 29, 2014 at 11:09:18AM -0800, Linus Torvalds wrote:
> So attached is the incremental diff of the patch by Sage and Ilya, and
> I'll apply it (delayed a bit to see if I can get the sign-off from
> Ilya), but I also think we should fix the (non-cached) ACL functions
> that call down to th
On Wed, Jan 29, 2014 at 6:37 PM, Ilya Dryomov wrote:
> From: Sage Weil
>
> The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
> ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
> dropping the now-generic functions and setting the set_acl inode op.
>
> Sign
On Wed, Jan 29, 2014 at 8:37 AM, Ilya Dryomov wrote:
> From: Sage Weil
>
> The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
> ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
> dropping the now-generic functions and setting the set_acl inode op.
>
> Sign
From: Sage Weil
The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
dropping the now-generic functions and setting the set_acl inode op.
Signed-off-by: Sage Weil
---
v2: fixed the !CONFIG_CEPH_FS_POSIX_ACL
28 matches
Mail list logo
