Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-20 at 17:24 +1300, Eric W. Biederman wrote: > James Bottomley writes: > > > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: > > > I think I am missing something but I completely do not understand > > > that subthread that says

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-20 at 17:24 +1300, Eric W. Biederman wrote: > James Bottomley writes: > > > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: > > > I think I am missing something but I completely do not understand > > > that subthread that says use file marks and perform the work in >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley: > With a different owner view, but that's irrelevant to the underlying > inode. Ok, the different ownership is limited within shitfs (or userns, container). Good. I might forget that shiftfs wants to behave like bind-mount. And I noticed that shiftfs setattr() converts uid/gid

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley: > With a different owner view, but that's irrelevant to the underlying > inode. Ok, the different ownership is limited within shitfs (or userns, container). Good. I might forget that shiftfs wants to behave like bind-mount. And I noticed that shiftfs setattr() converts uid/gid

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-21 at 11:57 +0900, J. R. Okajima wrote: > James Bottomley: > > I realised as I was trimming down the vestigial inode properties in > > the patch that actually shiftfs does use the i_ino from the > > underlying for userspace. The reason why is that it comes from the > > getattr

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-21 at 11:57 +0900, J. R. Okajima wrote: > James Bottomley: > > I realised as I was trimming down the vestigial inode properties in > > the patch that actually shiftfs does use the i_ino from the > > underlying for userspace. The reason why is that it comes from the > > getattr

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley: > I realised as I was trimming down the vestigial inode properties in the > patch that actually shiftfs does use the i_ino from the underlying for > userspace. The reason why is that it comes from the getattr call in > stat and that's fully what the underlying filesystem returns

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley: > I realised as I was trimming down the vestigial inode properties in the > patch that actually shiftfs does use the i_ino from the underlying for > userspace. The reason why is that it comes from the getattr call in > stat and that's fully what the underlying filesystem returns

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 01:24 +0900, J. R. Okajima wrote: > James Bottomley: > > Yes, I know the problem. However, I believe most current linux > > filesystems no longer guarantee stable, for the lifetime of the > > file, inode numbers. The usual docker container root is overlayfs, > > which,

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 01:24 +0900, J. R. Okajima wrote: > James Bottomley: > > Yes, I know the problem. However, I believe most current linux > > filesystems no longer guarantee stable, for the lifetime of the > > file, inode numbers. The usual docker container root is overlayfs, > > which,

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-20 at 14:26 -0500, Vivek Goyal wrote: > On Sat, Feb 18, 2017 at 07:24:38PM -0800, James Bottomley wrote: > > [..] > > > > Yes, this is a known characteristic of stacked filesystems. Is > > > > there some magic I don't know about that would make it easier > > > > to > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-20 at 14:26 -0500, Vivek Goyal wrote: > On Sat, Feb 18, 2017 at 07:24:38PM -0800, James Bottomley wrote: > > [..] > > > > Yes, this is a known characteristic of stacked filesystems. Is > > > > there some magic I don't know about that would make it easier > > > > to > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 18, 2017 at 07:24:38PM -0800, James Bottomley wrote: [..] > > > Yes, this is a known characteristic of stacked filesystems. Is > > > there some magic I don't know about that would make it easier to > > > reflect hard links as aliases? > > > > I think overlayfs had the same issue

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 18, 2017 at 07:24:38PM -0800, James Bottomley wrote: [..] > > > Yes, this is a known characteristic of stacked filesystems. Is > > > there some magic I don't know about that would make it easier to > > > reflect hard links as aliases? > > > > I think overlayfs had the same issue

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: >> I think I am missing something but I completely do not understand >> that subthread that says use file marks and perform the work in the >> vfs. The problem is that

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: >> I think I am missing something but I completely do not understand >> that subthread that says use file marks and perform the work in the >> vfs. The problem is that fundamentally we need multiple mappings

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 15:35 -0500, Vivek Goyal wrote: > On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > > > Hi James, > > > > > > > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 15:35 -0500, Vivek Goyal wrote: > On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > > > Hi James, > > > > > > > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 17:51 +, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing > > > on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 17:51 +, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing > > > on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > Hi James, > > > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > Hi James, > > > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 05:51:18PM +, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 05:51:18PM +, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > What happens when somebody comes along and creates the damn thing on > > the underlying fs? _Not_ via your code, that is - using the > > underlying fs mounted elsewhere. > > Point taken. This, I think fixes the dcache

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > What happens when somebody comes along and creates the damn thing on > > the underlying fs? _Not_ via your code, that is - using the > > underlying fs mounted elsewhere. > > Point taken. This, I think fixes the dcache

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > Hi James, > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > alias it is returned back to caller and passed in dentry can be > > > freed.

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > Hi James, > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > alias it is returned back to caller and passed in dentry can be > > > freed.

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 02:29 +, Al Viro wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > > +static const struct dentry_operations shiftfs_dentry_ops = { > > + .d_release = shiftfs_d_release, > > + .d_real = shiftfs_d_real, > > +}; > > In other

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 02:29 +, Al Viro wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > > +static const struct dentry_operations shiftfs_dentry_ops = { > > + .d_release = shiftfs_d_release, > > + .d_real = shiftfs_d_real, > > +}; > > In other

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: > I think I am missing something but I completely do not understand > that subthread that says use file marks and perform the work in the > vfs. The problem is that fundamentally we need multiple mappings and > I don't see a mark on a

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote: > I think I am missing something but I completely do not understand > that subthread that says use file marks and perform the work in the > vfs. The problem is that fundamentally we need multiple mappings and > I don't see a mark on a

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 2:57 AM, Eric W. Biederman wrote: > James Bottomley writes: > >> On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: >>> On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: >>> >>> [..] >>> > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Fri, Feb 17, 2017 at 2:57 AM, Eric W. Biederman wrote: > James Bottomley writes: > >> On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: >>> On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: >>> >>> [..] >>> > > Two levels of checks will simplify this a bit. Top level inode

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > Hi James, > > > > Should it be "return d_splice_alias()" so that if we find an alias it > > is returned back to caller and passed in dentry can be freed. Though > > I don't know in what cases alias can be found. And if alias

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > Hi James, > > > > Should it be "return d_splice_alias()" so that if we find an alias it > > is returned back to caller and passed in dentry can be freed. Though > > I don't know in what cases alias can be found. And if alias

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > +static const struct dentry_operations shiftfs_dentry_ops = { > + .d_release = shiftfs_d_release, > + .d_real = shiftfs_d_real, > +}; In other words, those dentries are *never* revalidated. Nevermind that

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > +static const struct dentry_operations shiftfs_dentry_ops = { > + .d_release = shiftfs_d_release, > + .d_real = shiftfs_d_real, > +}; In other words, those dentries are *never* revalidated. Nevermind that

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: >> On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: >> >> [..] >> > > Two levels of checks will simplify this a bit. Top level inode >> > > will belong to the

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: >> On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: >> >> [..] >> > > Two levels of checks will simplify this a bit. Top level inode >> > > will belong to the user namespace of caller and checks

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: > On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: > > [..] > > > Two levels of checks will simplify this a bit. Top level inode > > > will belong to the user namespace of caller and checks should > > > pass. And mounter's

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, 2017-02-16 at 11:42 -0500, Vivek Goyal wrote: > On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: > > [..] > > > Two levels of checks will simplify this a bit. Top level inode > > > will belong to the user namespace of caller and checks should > > > pass. And mounter's

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: [..] > > Two levels of checks will simplify this a bit. Top level inode will > > belong to the user namespace of caller and checks should pass. And > > mounter's creds will have ownership over the real inode so no > > additional

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: [..] > > Two levels of checks will simplify this a bit. Top level inode will > > belong to the user namespace of caller and checks should pass. And > > mounter's creds will have ownership over the real inode so no > > additional

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-15 at 15:34 -0500, Vivek Goyal wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > [..] > > +static struct dentry *shiftfs_lookup(struct inode *dir, struct > > dentry *dentry, > > +unsigned int flags) > > +{ > > + struct

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-15 at 15:34 -0500, Vivek Goyal wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > [..] > > +static struct dentry *shiftfs_lookup(struct inode *dir, struct > > dentry *dentry, > > +unsigned int flags) > > +{ > > + struct

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-15 at 09:17 -0500, Vivek Goyal wrote: > On Tue, Feb 14, 2017 at 03:45:55PM -0800, James Bottomley wrote: > > On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: [...] > > > Given we have already shifted the uid/gid for shiftfs inode, I am > > > wondering that why can't we simply

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-15 at 09:17 -0500, Vivek Goyal wrote: > On Tue, Feb 14, 2017 at 03:45:55PM -0800, James Bottomley wrote: > > On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: [...] > > > Given we have already shifted the uid/gid for shiftfs inode, I am > > > wondering that why can't we simply

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: [..] > +static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry > *dentry, > + unsigned int flags) > +{ > + struct dentry *real = dir->i_private, *new; > + struct inode *reali

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: [..] > +static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry > *dentry, > + unsigned int flags) > +{ > + struct dentry *real = dir->i_private, *new; > + struct inode *reali

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 14, 2017 at 03:45:55PM -0800, James Bottomley wrote: > On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: > > On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: > > > > [..] > > > > shiftfs is going to miss out on overlayfs bug fixes related to > > > > user > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 14, 2017 at 03:45:55PM -0800, James Bottomley wrote: > On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: > > On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: > > > > [..] > > > > shiftfs is going to miss out on overlayfs bug fixes related to > > > > user > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 15, 2017 at 10:37 AM, Eric W. Biederman wrote: > Djalal Harouni writes: > >> On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman >> wrote: >>> James Bottomley writes: > So is

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 15, 2017 at 10:37 AM, Eric W. Biederman wrote: > Djalal Harouni writes: > >> On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman >> wrote: >>> James Bottomley writes: > So is this. Basically anything that begins by mounting gets a super block and can use the s_user_ns to

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

Djalal Harouni writes: > On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman > wrote: >> James Bottomley writes: >>> So is this. Basically anything that begins by mounting gets a super >>> block and can use the

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

Djalal Harouni writes: > On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman > wrote: >> James Bottomley writes: >>> So is this. Basically anything that begins by mounting gets a super >>> block and can use the s_user_ns to map from the filesystem view to the >>> kernel view of ids. Apart

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman wrote: > James Bottomley writes: > >> On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: >>> On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: >>> > On Tue,

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman wrote: > James Bottomley writes: > >> On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: >>> On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: >>> > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: >>> > > On Tue, Feb

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: > On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: > > [..] > > > shiftfs is going to miss out on overlayfs bug fixes related to > > > user > > > credentials differ from mounter credentials, like fd3220d ("ovl: > > > update

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: > On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: > > [..] > > > shiftfs is going to miss out on overlayfs bug fixes related to > > > user > > > credentials differ from mounter credentials, like fd3220d ("ovl: > > > update

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: [..] > > shiftfs is going to miss out on overlayfs bug fixes related to user > > credentials differ from mounter credentials, like fd3220d ("ovl: > > update S_ISGID when setting posix ACLs"). I am not sure that this > > specific

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: [..] > > shiftfs is going to miss out on overlayfs bug fixes related to user > > credentials differ from mounter credentials, like fd3220d ("ovl: > > update S_ISGID when setting posix ACLs"). I am not sure that this > > specific

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: >> On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: >> > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: >> > > On Tue, Feb 07, 2017 at 11:49:33AM

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

James Bottomley writes: > On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: >> On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: >> > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: >> > > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig >> > > wrote: >> >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: > On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: > > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > > > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig > > > wrote: > > > > On Tue, Feb 07, 2017 at

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Thu, 2017-02-09 at 02:36 -0800, Josh Triplett wrote: > On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: > > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > > > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig > > > wrote: > > > > On Tue, Feb 07, 2017 at

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > > > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > > > Another option would

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 08, 2017 at 07:22:45AM -0800, James Bottomley wrote: > On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > > > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > > > Another option would

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > > Another option would be to require something like a project > > > > as used > > > > for

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 17:54 -0800, Josh Triplett wrote: > On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > > Another option would be to require something like a project > > > > as used > > > > for

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-08 at 08:44 +0200, Amir Goldstein wrote: > On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley [...] > > So I've been thinking about how to do this without subtree marking > > and yet retain the subtree properties similar to project id. The > > advantage would be that if it can be

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-08 at 08:44 +0200, Amir Goldstein wrote: > On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley [...] > > So I've been thinking about how to do this without subtree marking > > and yet retain the subtree properties similar to project id. The > > advantage would be that if it can be

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-08 at 08:44 +0200, Amir Goldstein wrote: > On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley > wrote: > > On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: > > > On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, 2017-02-08 at 08:44 +0200, Amir Goldstein wrote: > On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley > wrote: > > On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: > > > On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > > > > Project id's are not exactly "subtree"

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On 08.02.2017 09:44, Amir Goldstein wrote: On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley wrote: On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: Project id's are not exactly

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On 08.02.2017 09:44, Amir Goldstein wrote: On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley wrote: On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: Project id's are not exactly "subtree" semantic, but inheritance

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley wrote: > On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: >> > Project id's are not exactly "subtree" semantic, but inheritance >> >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley wrote: > On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: >> > Project id's are not exactly "subtree" semantic, but inheritance >> > semantics, >> > which is not the same

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > Another option would be to require something like a project as used > > > for project quotas as the root. This would also be conveniant as it > > > could

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:49:33AM -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > Another option would be to require something like a project as used > > > for project quotas as the root. This would also be conveniant as it > > > could

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > > Project id's are not exactly "subtree" semantic, but inheritance > > semantics, > > which is not the same when non empty directories get their project > > id changed. >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > > Project id's are not exactly "subtree" semantic, but inheritance > > semantics, > > which is not the same when non empty directories get their project > > id changed. >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > Project id's are not exactly "subtree" semantic, but inheritance semantics, > which is not the same when non empty directories get their project id changed. > Here is a recap: > https://lwn.net/Articles/623835/ Yes - but if we

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > Project id's are not exactly "subtree" semantic, but inheritance semantics, > which is not the same when non empty directories get their project id changed. > Here is a recap: > https://lwn.net/Articles/623835/ Yes - but if we

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 7, 2017 at 10:05 PM, James Bottomley wrote: > On Tue, 2017-02-07 at 11:49 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: >> > > Another option would be to require something like a project as

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 7, 2017 at 10:05 PM, James Bottomley wrote: > On Tue, 2017-02-07 at 11:49 -0800, Christoph Hellwig wrote: >> On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: >> > > Another option would be to require something like a project as >> > > used >> > > for project quotas

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 11:49 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > Another option would be to require something like a project as > > > used > > > for project quotas as the root. This would also be conveniant as > > > it > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 11:49 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > > Another option would be to require something like a project as > > > used > > > for project quotas as the root. This would also be conveniant as > > > it > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > Another option would be to require something like a project as used > > for project quotas as the root. This would also be conveniant as it > > could storge the used remapping tables. > > So this would be like the current

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:02:03AM -0800, James Bottomley wrote: > > Another option would be to require something like a project as used > > for project quotas as the root. This would also be conveniant as it > > could storge the used remapping tables. > > So this would be like the current

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:01:08AM -0800, James Bottomley wrote: > I was talking about inode stability in the filesystem underlying the > export. I believe you're talking about inode number stability > guarantees of the nfs client code itself, which are unrelated to the > inode number guarantees

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 07, 2017 at 11:01:08AM -0800, James Bottomley wrote: > I was talking about inode stability in the filesystem underlying the > export. I believe you're talking about inode number stability > guarantees of the nfs client code itself, which are unrelated to the > inode number guarantees

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 7, 2017 at 7:20 PM, James Bottomley wrote: > On Tue, 2017-02-07 at 19:59 +0200, Amir Goldstein wrote: >> On Tue, Feb 7, 2017 at 6:37 PM, James Bottomley >> wrote: >> > On Tue, 2017-02-07 at 01:19 -0800,

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, Feb 7, 2017 at 7:20 PM, James Bottomley wrote: > On Tue, 2017-02-07 at 19:59 +0200, Amir Goldstein wrote: >> On Tue, Feb 7, 2017 at 6:37 PM, James Bottomley >> wrote: >> > On Tue, 2017-02-07 at 01:19 -0800, Christoph Hellwig wrote: >> > > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 10:10 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 07:59:00PM +0200, Amir Goldstein wrote: > > I am not even sure that would be enough. > > dentry does not contain information about the mount user came from, > > and sb contains only information about the user ns

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 10:10 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 07:59:00PM +0200, Amir Goldstein wrote: > > I am not even sure that would be enough. > > dentry does not contain information about the mount user came from, > > and sb contains only information about the user ns

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-06 at 20:35 -0500, J. Bruce Fields wrote: > On Mon, Feb 06, 2017 at 04:10:11PM -0800, James Bottomley wrote: > > On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > > > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > > > On Mon, 2017-02-06 at 09:50

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-06 at 20:35 -0500, J. Bruce Fields wrote: > On Mon, Feb 06, 2017 at 04:10:11PM -0800, James Bottomley wrote: > > On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > > > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > > > On Mon, 2017-02-06 at 09:50

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 19:59 +0200, Amir Goldstein wrote: > On Tue, Feb 7, 2017 at 6:37 PM, James Bottomley > wrote: > > On Tue, 2017-02-07 at 01:19 -0800, Christoph Hellwig wrote: > > > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Tue, 2017-02-07 at 19:59 +0200, Amir Goldstein wrote: > On Tue, Feb 7, 2017 at 6:37 PM, James Bottomley > wrote: > > On Tue, 2017-02-07 at 01:19 -0800, Christoph Hellwig wrote: > > > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > > > > This allows any subtree to be uid/gid

  1   2   >