| Message ID | 1438689218-6921-4-git-send-email-agruenba@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Aug 04, 2015 at 01:53:01PM +0200, Andreas Gruenbacher wrote: > Normally, deleting a file requires write and execute access to the parent > directory. With Richacls, a process with MAY_DELETE_SELF access to a file > may delete the file even without write access to the parent directory. > > To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() > when checking for delete access inside a directory, and MAY_DELETE_SELF > when checking for delete access to a file itelf. > > The MAY_DELETE_SELF permission does not override the sticky directory > check. It probably should. I guess it would basically just let the file owner delegate permission to delete your file to a non-owner? Makes sense to me to allow that. --b. > > Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> > --- > fs/namei.c | 15 +++++++++++---- > include/linux/fs.h | 2 ++ > 2 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/fs/namei.c b/fs/namei.c > index 3504d36..2ac759c 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -454,7 +454,7 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask) > * changing the "normal" UIDs which are used for other things. > * > * When checking for MAY_APPEND, MAY_CREATE_FILE, MAY_CREATE_DIR, > - * MAY_WRITE must also be set in @mask. > + * MAY_DELETE_CHILD, MAY_DELETE_SELF, MAY_WRITE must also be set in @mask. > */ > int inode_permission(struct inode *inode, int mask) > { > @@ -2527,7 +2527,7 @@ static int may_delete(struct inode *dir, struct dentry *victim, > bool isdir, bool replace) > { > struct inode *inode = d_backing_inode(victim); > - int error, mask = MAY_WRITE | MAY_EXEC; > + int error, mask = MAY_EXEC; > > if (d_is_negative(victim)) > return -ENOENT; > @@ -2537,8 +2537,15 @@ static int may_delete(struct inode *dir, struct dentry *victim, > audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE); > > if (replace) > - mask |= isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE; > - error = inode_permission(dir, mask); > + mask |= MAY_WRITE | (isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE); > + error = inode_permission(dir, mask | MAY_WRITE | MAY_DELETE_CHILD); > + if (error && IS_RICHACL(inode)) { > + /* Deleting is also permitted with MAY_EXEC on the directory > + * and MAY_DELETE_SELF on the inode. */ > + if (!inode_permission(inode, MAY_DELETE_SELF) && > + !inode_permission(dir, mask)) > + error = 0; > + } > if (error) > return error; > if (IS_APPEND(dir)) > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 9c44f27..abf5b0e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -83,6 +83,8 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int uptodate); > #define MAY_NOT_BLOCK 0x00000080 > #define MAY_CREATE_FILE 0x00000100 > #define MAY_CREATE_DIR 0x00000200 > +#define MAY_DELETE_CHILD 0x00000400 > +#define MAY_DELETE_SELF 0x00000800 > > /* > * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond > -- > 2.5.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-08-28 22:44 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: >> The MAY_DELETE_SELF permission does not override the sticky >> directory check. It probably should. > > I guess it would basically just let the file owner delegate permission > to delete your file to a non-owner? Makes sense to me to allow that. Yes, independent of whether or not the process has MAY_DELETE_CHILD access on the directory but not independent of the sticky directory check, which is a bit of a weird combination. Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 4, 2015 at 4:53 AM, Andreas Gruenbacher <andreas.gruenbacher@gmail.com> wrote: > Normally, deleting a file requires write and execute access to the parent > directory. With Richacls, a process with MAY_DELETE_SELF access to a file > may delete the file even without write access to the parent directory. > > To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() > when checking for delete access inside a directory, and MAY_DELETE_SELF > when checking for delete access to a file itelf. > > The MAY_DELETE_SELF permission does not override the sticky directory > check. It probably should. Silly question from the peanut gallery: is there any such thing as opening an fd pointing at a file such that the "open file description" (i.e. the struct file) captures the right to delete the file? IOW do we need FMODE_DELETE_SELF? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-08-28 23:36 GMT+02:00 Andy Lutomirski <luto@amacapital.net>: > Silly question from the peanut gallery: is there any such thing as > opening an fd pointing at a file such that the "open file description" > (i.e. the struct file) captures the right to delete the file? > > IOW do we need FMODE_DELETE_SELF? When would that permission be checked, what syscall would you use to unlink an open file descriptor? Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 28, 2015 at 02:36:15PM -0700, Andy Lutomirski wrote: > On Tue, Aug 4, 2015 at 4:53 AM, Andreas Gruenbacher > <andreas.gruenbacher@gmail.com> wrote: > > Normally, deleting a file requires write and execute access to the parent > > directory. With Richacls, a process with MAY_DELETE_SELF access to a file > > may delete the file even without write access to the parent directory. > > > > To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() > > when checking for delete access inside a directory, and MAY_DELETE_SELF > > when checking for delete access to a file itelf. > > > > The MAY_DELETE_SELF permission does not override the sticky directory > > check. It probably should. > > Silly question from the peanut gallery: is there any such thing as > opening an fd pointing at a file such that the "open file description" > (i.e. the struct file) captures the right to delete the file? > > IOW do we need FMODE_DELETE_SELF? I guess FMODE_READ and _WRITE make sense because we pass file descriptors to read() and write(). But we don't have a way to pass a file descriptor to an operation that deletes a file. (I think Windows may be different in both respects, it might be interesting to compare, but I really don't understand how it works...). --b. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Aug 28, 2015 2:54 PM, "Andreas Grünbacher" <andreas.gruenbacher@gmail.com> wrote: > > 2015-08-28 23:36 GMT+02:00 Andy Lutomirski <luto@amacapital.net>: > > Silly question from the peanut gallery: is there any such thing as > > opening an fd pointing at a file such that the "open file description" > > (i.e. the struct file) captures the right to delete the file? > > > > IOW do we need FMODE_DELETE_SELF? > > When would that permission be checked, what syscall would you use to > unlink an open file descriptor? Good point. It's remotely plausible that there's some trick with bind mounts, it's likely possible to unlink a directory by fd (using unlinkat), and you can *link* a file (with linkat or /proc), but unlinkat doesn't appear to allow you to unlink a file by fd. --Andy > > Thanks, > Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/namei.c b/fs/namei.c index 3504d36..2ac759c 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -454,7 +454,7 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask) * changing the "normal" UIDs which are used for other things. * * When checking for MAY_APPEND, MAY_CREATE_FILE, MAY_CREATE_DIR, - * MAY_WRITE must also be set in @mask. + * MAY_DELETE_CHILD, MAY_DELETE_SELF, MAY_WRITE must also be set in @mask. */ int inode_permission(struct inode *inode, int mask) { @@ -2527,7 +2527,7 @@ static int may_delete(struct inode *dir, struct dentry *victim, bool isdir, bool replace) { struct inode *inode = d_backing_inode(victim); - int error, mask = MAY_WRITE | MAY_EXEC; + int error, mask = MAY_EXEC; if (d_is_negative(victim)) return -ENOENT; @@ -2537,8 +2537,15 @@ static int may_delete(struct inode *dir, struct dentry *victim, audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE); if (replace) - mask |= isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE; - error = inode_permission(dir, mask); + mask |= MAY_WRITE | (isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE); + error = inode_permission(dir, mask | MAY_WRITE | MAY_DELETE_CHILD); + if (error && IS_RICHACL(inode)) { + /* Deleting is also permitted with MAY_EXEC on the directory + * and MAY_DELETE_SELF on the inode. */ + if (!inode_permission(inode, MAY_DELETE_SELF) && + !inode_permission(dir, mask)) + error = 0; + } if (error) return error; if (IS_APPEND(dir)) diff --git a/include/linux/fs.h b/include/linux/fs.h index 9c44f27..abf5b0e 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -83,6 +83,8 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int uptodate); #define MAY_NOT_BLOCK 0x00000080 #define MAY_CREATE_FILE 0x00000100 #define MAY_CREATE_DIR 0x00000200 +#define MAY_DELETE_CHILD 0x00000400 +#define MAY_DELETE_SELF 0x00000800 /* * flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
Normally, deleting a file requires write and execute access to the parent directory. With Richacls, a process with MAY_DELETE_SELF access to a file may delete the file even without write access to the parent directory. To support that, pass the MAY_DELETE_CHILD mask flag to inode_permission() when checking for delete access inside a directory, and MAY_DELETE_SELF when checking for delete access to a file itelf. The MAY_DELETE_SELF permission does not override the sticky directory check. It probably should. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> --- fs/namei.c | 15 +++++++++++---- include/linux/fs.h | 2 ++ 2 files changed, 13 insertions(+), 4 deletions(-)