Re: [Acl-devel] libattr 2.4.48 change in syscalls.c breaks fakechroot

[Filipe Brandenburger]

On Wed, Aug 15, 2018 at 09:50:14PM +0200, Andreas Grünbacher wrote:
> I wonder if there's a way to leave older versions of a symbol around
> in a library, but to un-export it in the default version so that
> programs newly built against the library will skip it. I couldn't
> figure out a way to do that though.

The version ATTR_1.0 is already non-default, so new binaries won't
link to these symbols and use the ones from glibc anymore. That's not
really the issue.

On Wed, Aug 15, 2018 at 2:49 PM Dmitry V. Levin <address@hidden> wrote:
> Both fakechroot and fakeroot implement the following naive algorithm:
> - add their own *attr functions;
> - each of these functions in turn calls dlsym(RTLD_NEXT) and obtains
>   a reference to another function with the same name implemented somewhere 
> else;
> - when libattr is loaded, these references point to functions in libattr,
>   otherwise they point to functions in glibc;
> - when libattr >= v2.4.48~11 is loaded, these referenced functions invoke
>   their sister functions from glibc;
> - these invocations get intercepted by fakechroot, causing a loop.

That's correct, that's exactly what happens.

> I had patched fakeroot to use dlvsym back in 2005, this is probably
> the reason why I haven't noticed any regressions 3 years ago.

I'm proposing that in fakechroot as well:
https://github.com/dex4er/fakechroot/pull/58

But, frankly, I don't think that is perfect either... Because when
chaining multiple LD_PRELOAD's that all want to intercept lsetxattr
and friends (for example, fakechroot + fakeroot), I want them to call
the hook in the next binary, not jump directly to the versioned one in
glibc...

As I said, I don't think this is libattr's fault. I'd say this is
really a limitation on how LD_PRELOAD and symbol versioning works.
This should have been designed better (or, designed, period.) But
unfortunately, that's the API we have...

Having said that, I really think it wouldn't hurt for libattr to
continue providing these compatibility symbols having them implemented
to do the syscalls themselves, using essentially the same code as
pre-commit v2.4.48~17. There's really no downside to that, since the
symbols are just there for compatibility anyways... That would prevent
all these issues with LD_PRELOAD and it doesn't seem to me like that
would be painful to maintain on libattr itself... Would you consider
going back to using syscalls?

Thanks!
Filipe

smime.p7s
Description: S/MIME Cryptographic Signature