linux-kernel - Re: [RFC][PATCH] VFS: create /proc/<pid>/mountinfo

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: <E1JHlLA-0003jk-Ee@pomaz-ex.szeredi.hu>
Date:	Wed, 23 Jan 2008 20:32:52 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hpa@...or.com
CC:	pavel@....cz, miklos@...redi.hu, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	util-linux-ng@...r.kernel.org, linuxram@...ibm.com,
	viro@....linux.org.uk, hch@...radead.org, a.p.zijlstra@...llo.nl
Subject: Re: [RFC][PATCH] VFS: create /proc/<pid>/mountinfo

> Pavel Machek wrote:
> > On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
> >>> Miklos Szeredi wrote:
> >>>> - for mount ID's use IDA (from the IDR library) instead of a 32bit
> >>>>   counter, which could overflow
> >>> IDAs tend to get reused quickly, which can cause race conditions.  Any 
> >>> reason not to just use a 64-bit counter?
> >> They tend to become hard to parse/compare for humans after a while.
> >> And all this is basically only for humans, so race conditions don't
> >> really matter.  Also a changed mount with a reused ID is easily
> >> identified by comparing the other fields.
> > 
> > Hmm, smart humans only compare last few digits if they don't care
> > about 100% reliability, and dumb software compares 64bits easily...
> > 							Pavel
> 
> Indeed.
> 
> And this is most certainly NOT only for humans, and race conditions most 
> certainly matter.

Use case please?  What will this info be used for, other than for
feedback for humans about the state of the propagation tree?

Face it, userspace is inherently racy.  Inode numbers, device numbers,
whatever are being reused all the time, we live with it, even if it's
programs, and not just humans.

But it's not even an important design decision, the ID allocation can
be swapped at any time.  If you insist, I'll change it to a 64bit
counter, and it'll just suck a little more, but no permanent damage
done ;)

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