Re: [PATCH 0/2] Squashing long inodes.

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Mar 05, 2014 at 06:05:17PM +0100, OndÅej BÃlka wrote:
> On Wed, Mar 05, 2014 at 05:32:23PM +0400, Denis Obrezkov wrote:
> > I understand that glibc has its own global purposes and its own view
> > on the problem. Let me introduce user's view.
> > First of all, I completely agree that programs should be compiled
> > with _FILE_OFFSET_BITS defined to 64. Also I believe that one day all
> > programs will use only proper structures for proper aims.
> > But unfortunately today isn't this day, probably tomorrow isn't too.
> > Thus we have some legacy programs which couldn't be recompiled at all
> > and programs which couldn't be recompiled with this flag due to their
> > nature(mixing 32bit and 64bit things will cause undefined behavior).
> > And these programs aren't work because hundreds of packages and
> > libraries
> > use stat only to make sure themselves that needed file exists. They
> > fail
> > every time when they want to checkout file's existence. I think it's
> > more serious bug than all the bugs which may be caused by squashing.
> > Also in this case(changing somehow inodes) we could take care of users
> > by outputting some kind of dmesg that squashing s used. So the
> > question is:
> > could you tell me what is the better way - squash or zeroing?
> > Even if we wouldn't do something with inode in glibc, we, simple users,
> > have to make our programs work.
> 
> A problem is that we cannot introduce a unreliable solution as default.

I agree completely. Squashing inode numbers is very dangerous and
could lead to all sorts of problems, possibly security-critical (e.g.
a program could see that a file it's opening matches the dev/ino
numbers of a file it's already loaded and use the already-loaded copy,
misinterpreting data or even clobbering the file contents).

> It could be enabled by a environment variable but also as indepent
> library.

This variable would need to be ignored for suid,etc. (naturally).

> Creating library that does this by overriding stat functions preferably
> by using hash table and giving 32bit inode numbers sequentialy has
> advantage that you do not have to ask anybody for permission.
> 
> Of course hard part is to make people use it.

Ensuring that programs calling the 32-bit stat fail often is a good
way to make sure people use it... :-)

Rich