Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
ebied...@xmission.com (Eric W. Biederman) writes: > So there is the basic question do we want to read the raw bytes on disk > or do we want to return something meaningful to the reader. As the > existing tools use the xattr interface to set/clear fscaps returning > data to user space rather than raw bytes seems the perfered interface. > > My ideal semantics would be: > > - If current_user_ns() == sb->s_user_ns return the raw data. > > I don't know how to implement this first scenario while permitting > stacked filesystems. After a little more thought I do. In getxattr if the get_cap method is not implemented by the filesystem if current_user_ns() == sb->s_user_ns simply treat it as an ordinary xattr read/write. Otherwise call vfs_get_cap and translate the result as described below. The key point of this is it allows for seeing what is actually on disk (when it is not confusing). > - Calculate the cpu_vfs_cap_data as get_vfs_caps_from_disk does. > That gives the meaning of the xattr. > > - If "from_kuid(current_userns(), krootid) == 0" return a v2 cap. > > - If "rootid_owns_currentns()" return a v2 cap. > > - Else return an error. Probably a permission error. > > The fscap simply can not make sense to the user if the rootid does not > map. Return a v2 cap would imply that the caps are present on the > executable (in the current context) which they are not. Eric
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
Miklos Szeredi writes: > On Tue, Jan 12, 2021 at 1:15 AM Eric W. Biederman > wrote: >> >> Miklos Szeredi writes: >> >> > On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote: > >> > For one: a v2 fscap is supposed to be equivalent to a v3 fscap with a >> > rootid of >> > zero, right? >> >> Yes. This assumes that everything is translated into the uids of the >> target filesystem. >> >> > If so, why does cap_inode_getsecurity() treat them differently (v2 fscap >> > succeeding unconditionally while v3 one being either converted to v2, >> > rejected >> > or left as v3 depending on current_user_ns())? >> >> As I understand it v2 fscaps have always succeeded unconditionally. The >> only case I can see for a v2 fscap might not succeed when read is if the >> filesystem is outside of the initial user namespace. > > Looking again, it's rather confusing. cap_inode_getsecurity() > currently handles the following cases: > > v1: -> fails with -EINVAL > > v2: -> returns unconverted xattr > > v3: > a) rootid is mapped in the current namespace to non-zero: > -> convert rootid > > b) rootid owns the current or ancerstor namespace: > -> convert to v2 > > c) rootid is not mapped and is not owner: > -> return -EOPNOTSUPP -> falls back to unconverted v3 > > So lets take the example, where a tmpfs is created in a private user > namespace and one file has a v2 cap and the other an equivalent v3 cap > with a zero rootid. This is the result when looking at it from > > 1) the namespace of the fs: > --- > t = cap_dac_override+eip > tt = cap_dac_override+eip > > 2) the initial namespace: > --- > t = cap_dac_override+eip > tt = cap_dac_override+eip [rootid=1000] > > 3) an unrelated namespace: > --- > t = cap_dac_override+eip > tt = cap_dac_override+eip > > Note: in this last case getxattr will actually return a v3 cap with > zero rootid for "tt" which getcap does not display due to being zero. > I could do a setup with a nested namespaces that better demonstrate > the confusing nature of this, but I think this also proves the point. Yes. There is real confusion on the reading case when the namespaces do not match. > At this point userspace simply cannot determine whether the returned > cap is in any way valid or not. > > The following semantics would make a ton more sense, since getting a > v2 would indicate that rootid is unknown: > - if cap is v2 convert to v3 with zero rootid > - after this, check if rootid needs to be translated, if not return v3 > - if yes, try to translate to current ns, if succeeds return translated v3 > - if not mappable, return v2 > > Hmm? So there is the basic question do we want to read the raw bytes on disk or do we want to return something meaningful to the reader. As the existing tools use the xattr interface to set/clear fscaps returning data to user space rather than raw bytes seems the perfered interface. My ideal semantics would be: - If current_user_ns() == sb->s_user_ns return the raw data. I don't know how to implement this first scenario while permitting stacked filesystems. - Calculate the cpu_vfs_cap_data as get_vfs_caps_from_disk does. That gives the meaning of the xattr. - If "from_kuid(current_userns(), krootid) == 0" return a v2 cap. - If "rootid_owns_currentns()" return a v2 cap. - Else return an error. Probably a permission error. The fscap simply can not make sense to the user if the rootid does not map. Return a v2 cap would imply that the caps are present on the executable (in the current context) which they are not. >> > Anyway, here's a patch that I think fixes getxattr() layering for >> > security.capability. Does basically what you suggested. Slight change of >> > semantics vs. v1 caps, not sure if that is still needed, >> > getxattr()/setxattr() >> > hasn't worked for these since the introduction of v3 in 4.14. >> > Untested. >> >> Taking a look. The goal of change how these operate is to make it so >> that layered filesystems can just pass through the data if they don't >> want to change anything (even with the user namespaces of the >> filesystems in question are different). >> >> Feedback on the code below: >> - cap_get should be in inode_operations like get_acl and set_acl. > > So it's not clear to me why xattr ops are per-sb and acl ops are per-inode. I don't know why either. What I do see is everything except inode->i_sb->s_xattr (the list of xattr handlers) is in inode_operations. Especially permission. So just for consistency I would keep everything in the inode_operations. >> - cap_get should return a cpu_vfs_cap_data. >> >> Which means that only make_kuid is needed when reading the cap from >> disk. > > It also means translating the cap bits back and forth between disk and > cpu endian. Not a big deal, but... For the very rare case of userspace reading and writing them. For
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
On Tue, Jan 12, 2021 at 10:43 AM Miklos Szeredi wrote: > The following semantics would make a ton more sense, since getting a > v2 would indicate that rootid is unknown: > > - if cap is v2 convert to v3 with zero rootid > - after this, check if rootid needs to be translated, if not return v3 > - if yes, try to translate to current ns, if succeeds return translated v3 > - if not mappable, return v2 > > Hmm? Actually, it would make even more sense to simply skip unconvertible caps and return -ENODATA. In fact that's what I thought would happen until I looked at the -EOPNOTSUPP fallback code in vfs_getxattr(). Serge, do you remember what was the reason for the unconverted fallback? Thanks, Miklos
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
On Tue, Jan 12, 2021 at 1:15 AM Eric W. Biederman wrote: > > Miklos Szeredi writes: > > > On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote: > > For one: a v2 fscap is supposed to be equivalent to a v3 fscap with a > > rootid of > > zero, right? > > Yes. This assumes that everything is translated into the uids of the > target filesystem. > > > If so, why does cap_inode_getsecurity() treat them differently (v2 fscap > > succeeding unconditionally while v3 one being either converted to v2, > > rejected > > or left as v3 depending on current_user_ns())? > > As I understand it v2 fscaps have always succeeded unconditionally. The > only case I can see for a v2 fscap might not succeed when read is if the > filesystem is outside of the initial user namespace. Looking again, it's rather confusing. cap_inode_getsecurity() currently handles the following cases: v1: -> fails with -EINVAL v2: -> returns unconverted xattr v3: a) rootid is mapped in the current namespace to non-zero: -> convert rootid b) rootid owns the current or ancerstor namespace: -> convert to v2 c) rootid is not mapped and is not owner: -> return -EOPNOTSUPP -> falls back to unconverted v3 So lets take the example, where a tmpfs is created in a private user namespace and one file has a v2 cap and the other an equivalent v3 cap with a zero rootid. This is the result when looking at it from 1) the namespace of the fs: --- t = cap_dac_override+eip tt = cap_dac_override+eip 2) the initial namespace: --- t = cap_dac_override+eip tt = cap_dac_override+eip [rootid=1000] 3) an unrelated namespace: --- t = cap_dac_override+eip tt = cap_dac_override+eip Note: in this last case getxattr will actually return a v3 cap with zero rootid for "tt" which getcap does not display due to being zero. I could do a setup with a nested namespaces that better demonstrate the confusing nature of this, but I think this also proves the point. At this point userspace simply cannot determine whether the returned cap is in any way valid or not. The following semantics would make a ton more sense, since getting a v2 would indicate that rootid is unknown: - if cap is v2 convert to v3 with zero rootid - after this, check if rootid needs to be translated, if not return v3 - if yes, try to translate to current ns, if succeeds return translated v3 - if not mappable, return v2 Hmm? > > Anyway, here's a patch that I think fixes getxattr() layering for > > security.capability. Does basically what you suggested. Slight change of > > semantics vs. v1 caps, not sure if that is still needed, > > getxattr()/setxattr() > > hasn't worked for these since the introduction of v3 in 4.14. > > Untested. > > Taking a look. The goal of change how these operate is to make it so > that layered filesystems can just pass through the data if they don't > want to change anything (even with the user namespaces of the > filesystems in question are different). > > Feedback on the code below: > - cap_get should be in inode_operations like get_acl and set_acl. So it's not clear to me why xattr ops are per-sb and acl ops are per-inode. > - cap_get should return a cpu_vfs_cap_data. > > Which means that only make_kuid is needed when reading the cap from > disk. It also means translating the cap bits back and forth between disk and cpu endian. Not a big deal, but... > Which means that except for the rootid_owns_currentns check (which > needs to happen elsewhere) default_cap_get should be today's > get_vfs_cap_from_disk. That's true. So what's the deal with v1 caps? Support was silently dropped for getxattr/setxattr but remained in get_vfs_caps_from_disk() (I guess to not break legacy disk images), but maybe it's time to deprecate v1 caps completely? > - With the introduction of cap_get I believe commoncap should stop > implementing the security_inode_getsecurity hook, and rather have > getxattr observe is the file capability xatter and call the new > vfs_cap_get then translate to a v2 or v3 cap as appropriate when > returning the cap to userspace. Confused. vfs_cap_get() is the one the layered filesystem will recurse with, so it must not translate the cap. The one to do that would be __vfs_getxattr(), right? Thanks, Miklos
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
Miklos Szeredi writes:
> On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
>> Miklos Szeredi writes:
>>
>> > cap_convert_nscap() does permission checking as well as conversion of the
>> > xattr value conditionally based on fs's user-ns.
>> >
>> > This is needed by overlayfs and probably other layered fs (ecryptfs) and is
>> > what vfs_foo() is supposed to do anyway.
>>
>> Well crap.
>>
>> I just noticed this and it turns out this change is wrong.
>>
>> The problem is that it reads the rootid from the v3 fscap, using
>> current_user_ns() and then writes it using the sb->s_user_ns.
>>
>> So any time the stacked filesystems sb->s_user_ns do not match or
>> current_user_ns does not match sb->s_user_ns this could be a problem.
>>
>> In a stacked filesystem a second pass through vfs_setxattr will result
>> in the rootid being translated a second time (with potentially the wrong
>> namespaces). I think because of the security checks a we won't write
>> something we shouldn't be able to write to the filesystem. Still we
>> will be writing the wrong v3 fscap which can go quite badly.
>>
>> This doesn't look terribly difficult to fix.
>>
>> Probably convert this into a fs independent form using uids in
>> init_user_ns at input and have cap_convert_nscap convert the v3 fscap
>> into the filesystem dependent form. With some way for stackable
>> filesystems to just skip converting it from the filesystem independent
>> format.
>>
>> Uids in xattrs that are expected to go directly to disk, but aren't
>> always suitable for going directly to disk are tricky.
>
> I've been looking at this for a couple of days and can't say I clearly
> understand everything yet.
>
> For one: a v2 fscap is supposed to be equivalent to a v3 fscap with a rootid
> of
> zero, right?
Yes. This assumes that everything is translated into the uids of the
target filesystem.
> If so, why does cap_inode_getsecurity() treat them differently (v2 fscap
> succeeding unconditionally while v3 one being either converted to v2, rejected
> or left as v3 depending on current_user_ns())?
As I understand it v2 fscaps have always succeeded unconditionally. The
only case I can see for a v2 fscap might not succeed when read is if the
filesystem is outside of the initial user namespace.
> Anyway, here's a patch that I think fixes getxattr() layering for
> security.capability. Does basically what you suggested. Slight change of
> semantics vs. v1 caps, not sure if that is still needed, getxattr()/setxattr()
> hasn't worked for these since the introduction of v3 in 4.14.
> Untested.
Taking a look. The goal of change how these operate is to make it so
that layered filesystems can just pass through the data if they don't
want to change anything (even with the user namespaces of the
filesystems in question are different).
Feedback on the code below:
- cap_get should be in inode_operations like get_acl and set_acl.
- cap_get should return a cpu_vfs_cap_data.
Which means that only make_kuid is needed when reading the cap from
disk.
Which means that except for the rootid_owns_currentns check (which
needs to happen elsewhere) default_cap_get should be today's
get_vfs_cap_from_disk.
- With the introduction of cap_get I believe commoncap should stop
implementing the security_inode_getsecurity hook, and rather have
getxattr observe is the file capability xatter and call the new
vfs_cap_get then translate to a v2 or v3 cap as appropriate when
returning the cap to userspace.
I think that would put the code on a solid comprehensible foundation.
Eric
> I still need to wrap my head around the permission requirements for the
> setxattr() case...
>
> Thanks,
> Miklos
>
> ---
> fs/overlayfs/super.c | 15 +++
> include/linux/capability.h |2
> include/linux/fs.h |1
> security/commoncap.c | 210
> -
> 4 files changed, 132 insertions(+), 96 deletions(-)
>
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -395,6 +395,20 @@ static int ovl_remount(struct super_bloc
> return ret;
> }
>
> +static int ovl_cap_get(struct dentry *dentry,
> +struct vfs_ns_cap_data *nscap)
> +{
> + int res;
> + const struct cred *old_cred;
> + struct dentry *realdentry = ovl_dentry_real(dentry);
> +
> + old_cred = ovl_override_creds(dentry->d_sb);
> + res = vfs_cap_get(realdentry, nscap);
> + revert_creds(old_cred);
> +
> + return res;
> +}
> +
> static const struct super_operations ovl_super_operations = {
> .alloc_inode= ovl_alloc_inode,
> .free_inode = ovl_free_inode,
> @@ -405,6 +419,7 @@ static const struct super_operations ovl
> .statfs = ovl_statfs,
> .show_options = ovl_show_options,
> .remount_fs = ovl_remount,
> + .cap_get= ovl_cap_get,
> };
>
> enum {
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
> Miklos Szeredi writes:
>
> > cap_convert_nscap() does permission checking as well as conversion of the
> > xattr value conditionally based on fs's user-ns.
> >
> > This is needed by overlayfs and probably other layered fs (ecryptfs) and is
> > what vfs_foo() is supposed to do anyway.
>
> Well crap.
>
> I just noticed this and it turns out this change is wrong.
>
> The problem is that it reads the rootid from the v3 fscap, using
> current_user_ns() and then writes it using the sb->s_user_ns.
>
> So any time the stacked filesystems sb->s_user_ns do not match or
> current_user_ns does not match sb->s_user_ns this could be a problem.
>
> In a stacked filesystem a second pass through vfs_setxattr will result
> in the rootid being translated a second time (with potentially the wrong
> namespaces). I think because of the security checks a we won't write
> something we shouldn't be able to write to the filesystem. Still we
> will be writing the wrong v3 fscap which can go quite badly.
>
> This doesn't look terribly difficult to fix.
>
> Probably convert this into a fs independent form using uids in
> init_user_ns at input and have cap_convert_nscap convert the v3 fscap
> into the filesystem dependent form. With some way for stackable
> filesystems to just skip converting it from the filesystem independent
> format.
>
> Uids in xattrs that are expected to go directly to disk, but aren't
> always suitable for going directly to disk are tricky.
I've been looking at this for a couple of days and can't say I clearly
understand everything yet.
For one: a v2 fscap is supposed to be equivalent to a v3 fscap with a rootid of
zero, right?
If so, why does cap_inode_getsecurity() treat them differently (v2 fscap
succeeding unconditionally while v3 one being either converted to v2, rejected
or left as v3 depending on current_user_ns())?
Anyway, here's a patch that I think fixes getxattr() layering for
security.capability. Does basically what you suggested. Slight change of
semantics vs. v1 caps, not sure if that is still needed, getxattr()/setxattr()
hasn't worked for these since the introduction of v3 in 4.14. Untested.
I still need to wrap my head around the permission requirements for the
setxattr() case...
Thanks,
Miklos
---
fs/overlayfs/super.c | 15 +++
include/linux/capability.h |2
include/linux/fs.h |1
security/commoncap.c | 210 -
4 files changed, 132 insertions(+), 96 deletions(-)
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -395,6 +395,20 @@ static int ovl_remount(struct super_bloc
return ret;
}
+static int ovl_cap_get(struct dentry *dentry,
+ struct vfs_ns_cap_data *nscap)
+{
+ int res;
+ const struct cred *old_cred;
+ struct dentry *realdentry = ovl_dentry_real(dentry);
+
+ old_cred = ovl_override_creds(dentry->d_sb);
+ res = vfs_cap_get(realdentry, nscap);
+ revert_creds(old_cred);
+
+ return res;
+}
+
static const struct super_operations ovl_super_operations = {
.alloc_inode= ovl_alloc_inode,
.free_inode = ovl_free_inode,
@@ -405,6 +419,7 @@ static const struct super_operations ovl
.statfs = ovl_statfs,
.show_options = ovl_show_options,
.remount_fs = ovl_remount,
+ .cap_get= ovl_cap_get,
};
enum {
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -272,4 +272,6 @@ extern int get_vfs_caps_from_disk(const
extern int cap_convert_nscap(struct dentry *dentry, const void **ivalue,
size_t size);
+int vfs_cap_get(struct dentry *dentry, struct vfs_ns_cap_data *nscap);
+
#endif /* !_LINUX_CAPABILITY_H */
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1963,6 +1963,7 @@ struct super_operations {
struct shrink_control *);
long (*free_cached_objects)(struct super_block *,
struct shrink_control *);
+ int (*cap_get)(struct dentry *dentry, struct vfs_ns_cap_data *nscap);
};
/*
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -341,6 +341,13 @@ static __u32 sansflags(__u32 m)
return m & ~VFS_CAP_FLAGS_EFFECTIVE;
}
+static bool is_v1header(size_t size, const struct vfs_cap_data *cap)
+{
+ if (size != XATTR_CAPS_SZ_1)
+ return false;
+ return sansflags(le32_to_cpu(cap->magic_etc)) == VFS_CAP_REVISION_1;
+}
+
static bool is_v2header(size_t size, const struct vfs_cap_data *cap)
{
if (size != XATTR_CAPS_SZ_2)
@@ -355,6 +362,72 @@ static bool is_v3header(size_t size, con
return sansflags(le32_to_cpu(cap->magic_etc)) == VFS_CAP_REVISION_3;
}
+static bool validheader(size_t size, const struct vfs_cap_data *cap)
+{
+ return is_v1header(size, cap) || is_v2header(size, cap) ||
is_v3header(size, cap);
+}
+
+static void
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
Miklos Szeredi writes:
> cap_convert_nscap() does permission checking as well as conversion of the
> xattr value conditionally based on fs's user-ns.
>
> This is needed by overlayfs and probably other layered fs (ecryptfs) and is
> what vfs_foo() is supposed to do anyway.
Well crap.
I just noticed this and it turns out this change is wrong.
The problem is that it reads the rootid from the v3 fscap, using
current_user_ns() and then writes it using the sb->s_user_ns.
So any time the stacked filesystems sb->s_user_ns do not match or
current_user_ns does not match sb->s_user_ns this could be a problem.
In a stacked filesystem a second pass through vfs_setxattr will result
in the rootid being translated a second time (with potentially the wrong
namespaces). I think because of the security checks a we won't write
something we shouldn't be able to write to the filesystem. Still we
will be writing the wrong v3 fscap which can go quite badly.
This doesn't look terribly difficult to fix.
Probably convert this into a fs independent form using uids in
init_user_ns at input and have cap_convert_nscap convert the v3 fscap
into the filesystem dependent form. With some way for stackable
filesystems to just skip converting it from the filesystem independent
format.
Uids in xattrs that are expected to go directly to disk, but aren't
always suitable for going directly to disk are tricky.
Eric
> Signed-off-by: Miklos Szeredi
> ---
> fs/xattr.c | 17 +++--
> include/linux/capability.h | 2 +-
> security/commoncap.c | 3 +--
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index cd7a563e8bcd..fd57153b1f61 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -276,8 +276,16 @@ vfs_setxattr(struct dentry *dentry, const char *name,
> const void *value,
> {
> struct inode *inode = dentry->d_inode;
> struct inode *delegated_inode = NULL;
> + const void *orig_value = value;
> int error;
>
> + if (size && strcmp(name, XATTR_NAME_CAPS) == 0) {
> + error = cap_convert_nscap(dentry, , size);
> + if (error < 0)
> + return error;
> + size = error;
> + }
> +
> retry_deleg:
> inode_lock(inode);
> error = __vfs_setxattr_locked(dentry, name, value, size, flags,
> @@ -289,6 +297,9 @@ vfs_setxattr(struct dentry *dentry, const char *name,
> const void *value,
> if (!error)
> goto retry_deleg;
> }
> + if (value != orig_value)
> + kfree(value);
> +
> return error;
> }
> EXPORT_SYMBOL_GPL(vfs_setxattr);
> @@ -537,12 +548,6 @@ setxattr(struct dentry *d, const char __user *name,
> const void __user *value,
> if ((strcmp(kname, XATTR_NAME_POSIX_ACL_ACCESS) == 0) ||
> (strcmp(kname, XATTR_NAME_POSIX_ACL_DEFAULT) == 0))
> posix_acl_fix_xattr_from_user(kvalue, size);
> - else if (strcmp(kname, XATTR_NAME_CAPS) == 0) {
> - error = cap_convert_nscap(d, , size);
> - if (error < 0)
> - goto out;
> - size = error;
> - }
> }
>
> error = vfs_setxattr(d, kname, kvalue, size, flags);
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 1e7fe311cabe..b2f698915c0f 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -270,6 +270,6 @@ static inline bool checkpoint_restore_ns_capable(struct
> user_namespace *ns)
> /* audit system wants to get cap info from files as well */
> extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct
> cpu_vfs_cap_data *cpu_caps);
>
> -extern int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t
> size);
> +extern int cap_convert_nscap(struct dentry *dentry, const void **ivalue,
> size_t size);
>
> #endif /* !_LINUX_CAPABILITY_H */
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 59bf3c1674c8..baccd871 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -473,7 +473,7 @@ static bool validheader(size_t size, const struct
> vfs_cap_data *cap)
> *
> * If all is ok, we return the new size, on error return < 0.
> */
> -int cap_convert_nscap(struct dentry *dentry, void **ivalue, size_t size)
> +int cap_convert_nscap(struct dentry *dentry, const void **ivalue, size_t
> size)
> {
> struct vfs_ns_cap_data *nscap;
> uid_t nsrootid;
> @@ -516,7 +516,6 @@ int cap_convert_nscap(struct dentry *dentry, void
> **ivalue, size_t size)
> nscap->magic_etc = cpu_to_le32(nsmagic);
> memcpy(>data, >data, sizeof(__le32) * 2 * VFS_CAP_U32);
>
> - kvfree(*ivalue);
> *ivalue = nscap;
> return newsize;
> }
Re: [PATCH v2 01/10] vfs: move cap_convert_nscap() call into vfs_setxattr()
On Mon, 7 Dec 2020, Miklos Szeredi wrote: > cap_convert_nscap() does permission checking as well as conversion of the > xattr value conditionally based on fs's user-ns. > > This is needed by overlayfs and probably other layered fs (ecryptfs) and is > what vfs_foo() is supposed to do anyway. > > Signed-off-by: Miklos Szeredi Acked-by: James Morris -- James Morris
