netdev - Re: [PATCH] CAN: Use inode instead of kernel address for /proc file

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D17270B.5000204@hartkopp.net>
Date:	Sun, 26 Dec 2010 12:29:15 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Dan Rosenberg <drosenberg@...curity.com>
CC:	Urs Thuermann <urs.thuermann@...kswagen.de>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	security@...nel.org
Subject: Re: [PATCH] CAN: Use inode instead of kernel address for /proc file

On 25.12.2010 23:41, Dan Rosenberg wrote:
> 
>>
>> One minor question:
>>
>> AFAIK the inode numbers that can be found in /proc/<pid>/fd/* are in decimal
>> and not in hex, right?
>>
>> If so, you should use '%lu' instead of '%lx' in the patch.
> 
> Yes, that's usually how they're expressed, but I did it this way for two
> reasons.  Firstly, %lu would require another change to the buffer size,
> since the output could be up to 20 bytes long (plus another for the NULL
> terminator).

This is not *really* a good reason as the buffer size can be changed easily
within the same patch, right? ;-)

> Secondly, by expressing it as hex it avoids breaking any
> userland utilities that are expecting addresses, even if no such
> utilities exist.

I'm very sure there are no userland utilities. And if there were any, they
only would use the filename as unique identifiers and can't do anything with
the (kernel)addresses - as you already stated in the patch description. E.g.
thinking of some shell script the content of the filename is pretty useless
unless it is unique.

The recent patch for the 64 bit compatibility broke the length of the filename
anyway, so IMO there's no real reason left to write the inode number as a hex
value for the unique filename.

Indeed having it a decimal number would bring some added value as you can
reference the filename to the numbers in /proc/<pid>/fd/* easily.

Convinced? 8-)

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html