linux-kernel - Re: [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers

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: <534D9D63.2050608@manux.info>
Date:	Tue, 15 Apr 2014 22:58:11 +0200
From:	Emmanuel Colbus <ecolbus@...ux.info>
To:	Theodore Ts'o <tytso@....edu>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers

Le 15/04/2014 22:19, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
>>> In addition the
>>> standards and common sense together pretty much imply that you need each
>>> device to at least have a unique identifier.
>>>
>>
>> Why is it? I mean, as far as userspace is concerned, they do have a
>> unique identifier : their name. How would it be problematic that the
>> software is unable to confirm that /dev/null is actually connected to
>> the usual /dev/null kernel driver? I mean, it's supposed to trust the OS
>> and its admin to have done their job properly, not second-guess them!
> 
> Backup programs will very often assume that if after two files, if
> stat(2)'ed, have the same st_ino and st_dev (which is a major/minor
> pair), then they are both hard links to the same underlying files.
> 
> There are also programs that will relying on st_dev for the purpose of
> honoring find -xdev, and there are also programs that may try to do
> intelligent things by assuming that st_dev and st_ino togehter will
> uniquely name the same content.  This gets tricky for remote file
> systems to get right, but file systems that don't at least try to get
> this right can end up triggering some very hard to debug userspace
> bugs.  Transarc's Andrew File System (AFS) would occasionally break
> this property, back in the late 1990's, and it was the cause of Much
> Hilarity (except on the part of the programmers who had to figure out
> why certain programs were stuck looping forever while trying to
> analyze a long AFS pathname...)

Yes, in fact, I do respect the unicity of the st_dev field, so all these
assumptions work. The only thing I'm doing is violating the assumption
that, if a file has a certain major and minor numbers according to its
st_dev field, then there is a special block file in /dev that has the
same major and minor numbers and that corresponds to the storage
peripheral where this file is stored.

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