linux-kernel - Re: securityfs_create

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: <Pine.LNX.4.61.0702211840140.12039@yvahk01.tjqt.qr>
Date:	Wed, 21 Feb 2007 18:46:33 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Greg KH <greg@...ah.com>
cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: securityfs_create_dir strange comment

Hi Greg,

>> >Try this instead:
>> >	if (!de)
>> >		return -ENOMEM;
>> >	if ((IS_ERR(de)) && (PTR_ERR(de) != -ENODEV))
>> >		return PTR_ERR(de);
>> >	return 0;
>> >
>> >That should cover everything properly, right?
>> 
>> In case memory could not be allocated, why does not securityfs_*() return
>> ERR_PTR(-ENOMEM) then? (I think, that's the quintessential question after
>> all. And thanks for giving an example what to do in the ENODEV case.)
>
>Actually, in reading the code (which might have helped in the first
>place), we can never return NULL if securityfs is enabled.

So we're back to the confusing comment ;-)

>So you can just drop that first check entirely.
>
>Which makes me wonder, it might be easier to just return NULL if
>securityfs is not enabled in the kernel, as long as no one checks that
>improperly...

I have actually had a look into the tree who even uses securityfs.
The most prominent case are LSMs. They need CONFIG_SECURITY=y anyway,
so securityfs is always enabled for those. What remains seems to be
tpm_bios.c.


Jan
-- 
-
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/