linux-kernel - Re: [PATCH v3] Add security.* XATTR support for the UBIFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4FAD2144.2000902@grid-net.com>
Date:	Fri, 11 May 2012 07:25:08 -0700
From:	Subodh Nijsure <snijsure@...d-net.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
CC:	<linux-mtd@...ts.infradead.org>,
	<linux-security-module@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] Add security.* XATTR support for the UBIFS

On 05/11/2012 05:01 AM, Tetsuo Handa wrote:
> Subodh Nijsure wrote:
>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>> index ad6e550..cec3ffab 100644
>> --- a/fs/ubifs/dir.c
>> +++ b/fs/ubifs/dir.c
>> @@ -292,6 +292,14 @@ static int ubifs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
>>
> According to 3.4-rc6,
>
> 	mutex_unlock() is here.
>
>>   	ubifs_release_budget(c,&req);
>>   	insert_inode_hash(inode);
>> +
>> +	err = ubifs_init_security(dir, inode,&dentry->d_name);
>> +	if (err) {
>> +		ubifs_err("cannot initialize extended attribute, error %d",
>> +			  err);
>> +		goto out_cancel;
>> +	}
>> +
>>   	d_instantiate(dentry, inode);
>>   	return 0;
> out_cancel:
> 	mutex_unlock() is also here...
>
> Same for the rest.
I will double check, my tree is based off linux-rc2, may be I messed up 
things.
>> diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
>> index 85b2722..49c426a 100644
>> --- a/fs/ubifs/xattr.c
>> +++ b/fs/ubifs/xattr.c
>> @@ -568,3 +600,91 @@ out_free:
>>   	kfree(xent);
>>   	return err;
>>   }
>> +
>> +size_t
>> +ubifs_security_listxattr(struct dentry *d, char *list, size_t list_size,
>> +			 const char *name, size_t name_len, int flags)
>> +{
>> +	const int prefix_len = XATTR_SECURITY_PREFIX_LEN;
>> +	const size_t total_len = prefix_len + name_len + 1;
>> +	if (list&&  total_len<= list_size) {
>> +		memcpy(list, XATTR_SECURITY_PREFIX, prefix_len);
>> +		memcpy(list+prefix_len, name, name_len);
>> +		list[prefix_len + name_len] = '\0';
>> +	}
> If (list&&  total_len>  list_size), the caller will see total_len
> but no data is copied to list. Is it OK?
the above condition you referred to implies that caller passed in buffer 
that was too short, in that case we don't need to copy the data. Typical 
usage would be caller call listxattr with null and list size of zero, we 
return size of the buffer etc.

man listxattr
ssize_t listxattr (const char *path, char *list, size_t size);

        An empty buffer of size zero can be passed into these calls to 
return the current size of the list  of  extende attribute names, which 
can be used to estimate the size of a buffer which is sufficiently large 
to hold the list of names.

so the above code should be okay?
>> +	return total_len;
>> +}
>> +static int ubifs_initxattrs(struct inode *inode,
>> +			    const struct xattr *xattr_array, void *fs_info)
>> +{
>> +	const struct xattr *xattr;
>> +	char *name;
>> +	int err = 0;
>> +
>> +	for (xattr = xattr_array; xattr->name != NULL; xattr++) {
>> +		name = kmalloc(XATTR_SECURITY_PREFIX_LEN +
>> +			       strlen(xattr->name) + 1, GFP_NOFS);
> Maybe nice to have kstrdup2(const char *str1, const char *str2, gfp_t flags).
  I will modify that.
>> +		if (!name) {
>> +			err = -ENOMEM;
>> +			break;
>> +		}
>> +		strcpy(name, XATTR_SECURITY_PREFIX);
>> +		strcpy(name + XATTR_SECURITY_PREFIX_LEN, xattr->name);
>> +		err = __ubifs_setxattr(inode, name, xattr->value,
>> +				       xattr->value_len, 0);
>> +		kfree(name);
>> +		if (err<  0)
>> +			break;
>> +	}
>> +	return err;
>> +}
-Subodh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/