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

Date:	Tue, 15 Apr 2014 16:19:14 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Emmanuel Colbus <ecolbus@...ux.info>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers

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...)

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