[devel] [Fwd: [(nowhere)] fopen() calls __open]

[devel] [Fwd: [(nowhere)] fopen() calls __open]

[Alexander Bokovoy]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Интересная дискуссия по поводу того, как делать "перекрытия" файловых 
операций для glibc. В свете ближнего и среднего будущего о smbsh и 
аналогах, похоже, придется забыть. Все же, autofs/automount более 
грамотный подход.

-------- Исходное сообщение --------
Тема: [(nowhere)] fopen() calls __open
Дата: Fri, 12 May 2006 14:05:20 -0400
От: Derrell.Lipman@UnwiredUniverse.com
Отвечать: Derrell.Lipman@UnwiredUniverse.com
Кому: Andrew Tridgell <tridge@samba.org>
Копия: samba-technical <samba-technical@samba.org>

Hi Tridge,

Reference our conversation a few weeks ago about fopen() and smbsh:

I thought you might be interested in this thread where I hoped to get some
useful information from the glibc folks about how to have fopen() work
properly with smbsh.  As you can see from this thread, it's likely to be a
non-trivial effort...

Derrell



-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: file:///home/ab/tmp/nsmail-2.tmp --]
[-- Type: text/plain, Size: 414 bytes --]

Subject: Topics

Topics:
   fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
    Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()
   Re: fopen() calls __open()



[-- Attachment #3: file:///home/ab/tmp/nsmail-3.tmp --]
[-- Type: text/plain, Size: 1817 bytes --]

Date: Thu, 27 Apr 2006 12:55:28 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: libc-alpha@sourceware.org
Subject: fopen() calls __open()
Message-ID: <vesvx8jj.fsf@oberon-mail.internal>
MIME-Version: 1.0

Hi all,

I'm on the Samba team, responsible for the client library, which provides
Unix/Linux access to Windows networks.  As an example program for using that
library, I have an LD_PRELOAD library that traps primitive file system calls
and if the path is to /smb/... it maps to the Samba client library; otherwise
to RTLD_NEXT (glibc).  This all works great for most programs.  For the
primitives that are mapped, three versions of each are mapped: 0, 1 and 2
leading underscores (if such functions actually exist in the C library).  For
example, I map open, _open and __open (assuming they exist in the library).

The problem is that some internal non-primitive functions like fopen()
directly call __open(), and (from my read of the source, it appears that)
__open() is aliased to open() such that fopen()'s call to __open() isn't
trapped by my preload library.  This means that if the file
/smb/SERVER/SHARE/filename is open()ed, the file on the remote Windows server
gets properly opened, but if that same file is fopen()ed, no file is found
because the internal __open is called.

I know that I could override fopen() and friends (including any other "high-
level" functions that call internal versions of primitive functions), but
there's a fair amount of code involved in those, and reimplementing or
copying them for the sole purpose of compiling them such that they use the
overridden open() call seems a lot like overkill.

What can I do to cause fopen() in glibc to call the open() or _open() or
__open() in the preload instead of the internal __open?

Thanks in advance for your help!

Derrell



[-- Attachment #4: file:///home/ab/tmp/nsmail-4.tmp --]
[-- Type: text/plain, Size: 1345 bytes --]

Date: Thu, 27 Apr 2006 10:03:02 -0700
From: Ulrich Drepper <drepper@redhat.com>
To: Derrell.Lipman@UnwiredUniverse.com
CC: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <4450F946.6030909@redhat.com>
References: <vesvx8jj.fsf@oberon-mail.internal>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=====-=-="

--=====-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Derrell.Lipman@UnwiredUniverse.com wrote:
> What can I do to cause fopen() in glibc to call the open() or _open() or
> __open() in the preload instead of the internal __open?

Nothing.  Once a call enters glibc it won't leave it until it's down.
Exceptions: the malloc functions.  Everything is completely opaque and
that won't change.

--=20
=E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro St =
=E2=9E=A7 Mountain View, CA =E2=9D=96


--=====-=-=
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEUPlG2ijCOnn/RHQRAkP1AKCoppgcC3ED6IAPsDnkvFvNZWrm0QCgh1x2
TEPrztIc6KWT1bYwfPCrruM=
=dfId
-----END PGP SIGNATURE-----

--=====-=-=--


[-- Attachment #5: file:///home/ab/tmp/nsmail-5.tmp --]
[-- Type: text/plain, Size: 1201 bytes --]

Date: Thu, 27 Apr 2006 13:06:35 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <8xprx810.fsf@oberon-mail.internal>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
MIME-Version: 1.0

Ulrich Drepper <drepper@redhat.com> writes:

> Derrell.Lipman@UnwiredUniverse.com wrote:
>> What can I do to cause fopen() in glibc to call the open() or _open() or
>> __open() in the preload instead of the internal __open?
>
> Nothing.  Once a call enters glibc it won't leave it until it's down.
> Exceptions: the malloc functions.  Everything is completely opaque and
> that won't change.

Ok.  Thanks for the response.

I'm a bit confused as to why certain functions are weak and allowed to be
overridden (e.g. open, __open) but not higher-level functions that use them.
It seems a bit inconsistent, but I assume there's a reason.  If there's some
prior thread that explains this, I'd sure appreciate a pointer to it.
Otherwise, might you be able to explain why primitives can be overridden but
not such that the users of those primitives within the library use the
overridden versions?

Thanks!

Derrell



[-- Attachment #6: file:///home/ab/tmp/nsmail-6.tmp --]
[-- Type: text/plain, Size: 1524 bytes --]

Date: Thu, 27 Apr 2006 10:43:08 -0700
From: Ulrich Drepper <drepper@redhat.com>
To: Derrell.Lipman@UnwiredUniverse.com
CC: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <445102AC.5090505@redhat.com>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=======-=-="

--=======-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Derrell.Lipman@UnwiredUniverse.com wrote:
> I'm a bit confused as to why certain functions are weak and allowed to be
> overridden (e.g. open, __open)

Forget about weak.  The is no difference in the treatment of weak and
strong symbols when they are defined in DSOs.  They are all the same.
The aspect interesting for you is exported or not.  No internal libc
call except those to the malloc functions references names which are
exported.

--=20
=E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro St =
=E2=9E=A7 Mountain View, CA =E2=9D=96


--=======-=-=
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEUQKs2ijCOnn/RHQRAlGLAJwLv/XjQPFBwXltsOJ0CKSgbuVuNQCeJkXp
bzhGu/ARFzSNXOeL5sZramY=
=dxnk
-----END PGP SIGNATURE-----

--=======-=-=--


[-- Attachment #7: file:///home/ab/tmp/nsmail-7.tmp --]
[-- Type: text/plain, Size: 1377 bytes --]

Date: Thu, 27 Apr 2006 13:55:06 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <vesux5s5.fsf@oberon-mail.internal>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
MIME-Version: 1.0

Ulrich Drepper <drepper@redhat.com> writes:

> Derrell.Lipman@UnwiredUniverse.com wrote:
>> I'm a bit confused as to why certain functions are weak and allowed to be
>> overridden (e.g. open, __open)
>
> Forget about weak.  The is no difference in the treatment of weak and
> strong symbols when they are defined in DSOs.  They are all the same.
> The aspect interesting for you is exported or not.  No internal libc
> call except those to the malloc functions references names which are
> exported.

Ok.  So that means that if I want applications running over the Samba wrapper
(smbsh) to be able to call fopen() and have them open files on the remote
Windows server as currently works with open() and __open(), I need to put an
implementation of fopen() and friends into the LD_PRELOAD library as well.
I'm not looking forward to lugging around all that extra code, but it sounds
like that's my only choice.

If you have any other suggestions for me, I'd certainly like to hear them!

Thanks for your help,

Derrell



[-- Attachment #8: file:///home/ab/tmp/nsmail-8.tmp --]
[-- Type: text/plain, Size: 961 bytes --]

Date: Thu, 27 Apr 2006 14:04:17 -0700
From: Paul Eggert <eggert@CS.UCLA.EDU>
To: Derrell.Lipman@UnwiredUniverse.com
Cc: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <87lktqu3vy.fsf@penguin.cs.ucla.edu>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
	<vesux5s5.fsf@oberon-mail.internal>
MIME-Version: 1.0

Derrell.Lipman@UnwiredUniverse.com writes:

> If you have any other suggestions for me, I'd certainly like to hear them!

You're not alone in having this problem.  One approach is to supply a
your own modified libc that addresses the problem.  For an example of
this, you might take a look at Plash <http://plash.beasts.org/>; in
particular see the 2nd FAQ in <http://plash.beasts.org/faq.html>.

An idle thought: perhaps you can even use Plash's libc, or come up
with a slightly-modified libc that both Plash and you can use.



[-- Attachment #9: file:///home/ab/tmp/nsmail-9.tmp --]
[-- Type: text/plain, Size: 1269 bytes --]

Date: Fri, 28 Apr 2006 10:43:35 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: Paul Eggert <eggert@CS.UCLA.EDU>
Subject: Re: fopen() calls __open()
Message-ID: <d5f1rca0.fsf@oberon-mail.internal>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
	<vesux5s5.fsf@oberon-mail.internal>
	<87lktqu3vy.fsf@penguin.cs.ucla.edu>
MIME-Version: 1.0

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> Derrell.Lipman@UnwiredUniverse.com writes:
>
>> If you have any other suggestions for me, I'd certainly like to hear them!
>
> You're not alone in having this problem.  One approach is to supply a
> your own modified libc that addresses the problem.  For an example of
> this, you might take a look at Plash <http://plash.beasts.org/>; in
> particular see the 2nd FAQ in <http://plash.beasts.org/faq.html>.
>
> An idle thought: perhaps you can even use Plash's libc, or come up
> with a slightly-modified libc that both Plash and you can use.

Hi Paul,

Thanks for this information.  It looks interesting.  I'll look at it in more
detail when I get a chance (hopefully soon!).

Are you involved in the Plash project, a user of it, or just have some
knowledge of it?

Cheers,

Derrell



[-- Attachment #10: file:///home/ab/tmp/nsmail-10.tmp --]
[-- Type: text/plain, Size: 630 bytes --]

Date: Fri, 28 Apr 2006 13:14:42 -0700
From: Paul Eggert <eggert@CS.UCLA.EDU>
To: Derrell.Lipman@UnwiredUniverse.com
Subject: Re: fopen() calls __open()
Message-ID: <87d5f1wj7x.fsf@penguin.cs.ucla.edu>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
	<vesux5s5.fsf@oberon-mail.internal>
	<87lktqu3vy.fsf@penguin.cs.ucla.edu>
	<d5f1rca0.fsf@oberon-mail.internal>
MIME-Version: 1.0

Derrell.Lipman@UnwiredUniverse.com writes:

> Are you involved in the Plash project, a user of it, or just have some
> knowledge of it?

The last one.



[-- Attachment #11: file:///home/ab/tmp/nsmail-11.tmp --]
[-- Type: text/plain, Size: 617 bytes --]

Date: Sat, 29 Apr 2006 19:30:05 +0100
From: Mike Hearn <mike@plan99.net>
To: libc-alpha@sources.redhat.com
Subject: Re: fopen() calls __open()
Message-ID: <pan.2006.04.29.18.30.05.918294@plan99.net>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
	<vesux5s5.fsf@oberon-mail.internal>
MIME-Version: 1.0

On Thu, 27 Apr 2006 13:55:06 -0400, Derrell.Lipman wrote:
> If you have any other suggestions for me, I'd certainly like to hear them!

The alsa AOSS program contains fopen wrapping code you can use.

thanks -mike




[-- Attachment #12: file:///home/ab/tmp/nsmail-12.tmp --]
[-- Type: text/plain, Size: 726 bytes --]

Date: Sun, 30 Apr 2006 17:16:07 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: Mike Hearn <mike@plan99.net>
Subject: Re: fopen() calls __open()
Message-ID: <lktmahns.fsf@oberon-mail.internal>
References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
	<8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com>
	<vesux5s5.fsf@oberon-mail.internal>
	<pan.2006.04.29.18.30.05.918294@plan99.net>
MIME-Version: 1.0

Mike Hearn <mike@plan99.net> writes:

> On Thu, 27 Apr 2006 13:55:06 -0400, Derrell.Lipman wrote:
>> If you have any other suggestions for me, I'd certainly like to hear them!
>
> The alsa AOSS program contains fopen wrapping code you can use.

Thanks!  I'll check it out.

Derrell



[-- Attachment #13: file:///home/ab/tmp/nsmail-13.tmp --]
[-- Type: text/plain, Size: 635 bytes --]

Date: Sat, 29 Apr 2006 08:33:45 -0700
From: John Reiser <jreiser@BitWagon.com>
To: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <44538759.4040103@BitWagon.com>
MIME-Version: 1.0

Derrell.Lipman@UnwiredUniverse.com wrote:

> If you have any other suggestions for me, I'd certainly like to hear them!

For many particular cases, it is feasible to rewrite (patch) glibc
at runtime.  Disassemble to find the calls of interest, then change them.
Of course this is architecture dependent, and some modes of SELinux aim to
inhibit such modifications.  But on x86, x86_64, and PowerPC it is not
hard to do.

-- 



[-- Attachment #14: file:///home/ab/tmp/nsmail-14.tmp --]
[-- Type: text/plain, Size: 911 bytes --]

Date: Sun, 30 Apr 2006 17:17:01 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: John Reiser <jreiser@BitWagon.com>
Cc: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <hd4aahma.fsf@oberon-mail.internal>
References: <44538759.4040103@BitWagon.com>
MIME-Version: 1.0

John Reiser <jreiser@BitWagon.com> writes:

> Derrell.Lipman@UnwiredUniverse.com wrote:
>
>> If you have any other suggestions for me, I'd certainly like to hear them!
>
> For many particular cases, it is feasible to rewrite (patch) glibc
> at runtime.  Disassemble to find the calls of interest, then change them.
> Of course this is architecture dependent, and some modes of SELinux aim to
> inhibit such modifications.  But on x86, x86_64, and PowerPC it is not
> hard to do.

This is an interesting option to consider.  Can you point me to any
open-source applications that actually do this?

Thanks!

Derrell



[-- Attachment #15: file:///home/ab/tmp/nsmail-15.tmp --]
[-- Type: text/plain, Size: 1239 bytes --]

Date: Sun, 30 Apr 2006 15:49:19 -0700
From: John Reiser <jreiser@BitWagon.com>
To: Derrell.Lipman@UnwiredUniverse.com
CC: libc-alpha@sourceware.org
Subject: Re: fopen() calls __open()
Message-ID: <44553EEF.30104@BitWagon.com>
References: <44538759.4040103@BitWagon.com> <hd4aahma.fsf@oberon-mail.internal>
MIME-Version: 1.0

Derrell.Lipman@UnwiredUniverse.com wrote:
> John Reiser <jreiser@BitWagon.com> writes:
>>For many particular cases, it is feasible to rewrite (patch) glibc
>>at runtime. ...

> This is an interesting option to consider.  Can you point me to any
> open-source applications that actually do this?

The runtime loader itself (rtld, part of glibc) does patching when a module
is marked with DT_TEXTREL in its ElfXX_Dyn.  So look in the glibc source
for TEXTREL.  Of course one of the important ideas is that the relocation
entries ElfXX_Rel specify exactly _where_ do to the patching, whereas
your case might need a disassembler to find the locations.  The objcopy
module of the binutils project has disassemblers; there are others.

Two other projects which use runtime patching are:
  http://bitwagon.com/rtldi/rtldi.html  indirect runtime loader
  http://bitwagon.com/tub/tub.html      address-space manager

-- 

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Anton Farygin]

Alexander Bokovoy wrote:
> Интересная дискуссия по поводу того, как делать "перекрытия" файловых 
> операций для glibc. В свете ближнего и среднего будущего о smbsh и 
> аналогах, похоже, придется забыть. Все же, autofs/automount более 
> грамотный подход.

Вообще очень странно, что они не смогли перекрыть fopen(), ибо в 
fakechroot (лежит в Sisyphus) fopen() и fopen64() прекрасно перекрываются.

Другой вопрос, что это перекрытие естественно не работает для статически 
слинкованных приложений.

А во всём остальном - всё прекрасно. перекрываются все операции с файлами.

Rgds,
Rider

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Alexander Bokovoy]

Anton Farygin пишет:
> Alexander Bokovoy wrote:
>> Интересная дискуссия по поводу того, как делать "перекрытия" 
>> файловых операций для glibc. В свете ближнего и среднего будущего о
>>  smbsh и аналогах, похоже, придется забыть. Все же,
>> autofs/automount более грамотный подход.
> 
> Вообще очень странно, что они не смогли перекрыть fopen(), ибо в 
> fakechroot (лежит в Sisyphus) fopen() и fopen64() прекрасно 
> перекрываются.
> 
> Другой вопрос, что это перекрытие естественно не работает для 
> статически слинкованных приложений.
> 
> А во всём остальном - всё прекрасно. перекрываются все операции с 
> файлами.
Ты невнимателен. Невозможно перекрыть вызовы внутри glibc. Чтобы
"закрыть все", необходимо перекрывать все высокоуровневые и
низкоуровневые операции, а не только одну из этих групп. Очевидно, что
fakechroot это делает, но тут я сомневаюсь, что он делает это полностью
-- попользовав его в scratchbox-е, я увидел некоторое количество
странностей в поведении.

Понятно, что компилятор, make и аналогичные программы используют
относительно несложные шаблоны файловых операций, а вот реальные
приложения могут цеплять и более тяжелые случаи и тогда начнутся
проблемы. Я пытался гонять под fakechroot ту же Самбу (в qemu-arm), она
даже не поднялась, в то время как на реальном устройстве все было чудесно.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

On Fri, May 12, 2006 at 11:08:46PM +0400, Alexander Bokovoy wrote:
> Интересная дискуссия по поводу того, как делать "перекрытия" файловых 
> операций для glibc. В свете ближнего и среднего будущего о smbsh и 
> аналогах, похоже, придется забыть. Все же, autofs/automount более 
> грамотный подход.

Дискуссию пока не осилил.
Тем не менее хочу обратить внимание на plasticfs.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Anton Farygin]

Alexander Bokovoy wrote:
> Anton Farygin пишет:
>> Alexander Bokovoy wrote:
>>> Интересная дискуссия по поводу того, как делать "перекрытия" 
>>> файловых операций для glibc. В свете ближнего и среднего будущего о
>>>  smbsh и аналогах, похоже, придется забыть. Все же,
>>> autofs/automount более грамотный подход.
>> Вообще очень странно, что они не смогли перекрыть fopen(), ибо в 
>> fakechroot (лежит в Sisyphus) fopen() и fopen64() прекрасно 
>> перекрываются.
>>
>> Другой вопрос, что это перекрытие естественно не работает для 
>> статически слинкованных приложений.
>>
>> А во всём остальном - всё прекрасно. перекрываются все операции с 
>> файлами.
> Ты невнимателен. Невозможно перекрыть вызовы внутри glibc. Чтобы
> "закрыть все", необходимо перекрывать все высокоуровневые и
> низкоуровневые операции, а не только одну из этих групп. Очевидно, что
> fakechroot это делает, но тут я сомневаюсь, что он делает это полностью
> -- попользовав его в scratchbox-е, я увидел некоторое количество
> странностей в поведении.

Странностей там хоть отбавляй.

Кстати, если ты последний раз смотрел его достаточно давно - попробуй 
ещё раз. Я в течении последнего года добавил в него некоторое количество 
не перекрытых ранее операций.

> 
> Понятно, что компилятор, make и аналогичные программы используют
> относительно несложные шаблоны файловых операций, а вот реальные
> приложения могут цеплять и более тяжелые случаи и тогда начнутся
> проблемы. Я пытался гонять под fakechroot ту же Самбу (в qemu-arm), она
> даже не поднялась, в то время как на реальном устройстве все было чудесно.
> 

Да, это известно - в этом случае конечно надо выяснять кто именно 
остаётся не перекрытый и перекрывать его в том числе.

собственно именно таким образом он и разрабатывался.

Кстати, в debian fackechroot полностью переписали, может быть список 
перекрытых операций там более полон. Но в любом случае - это всё 
выглядит как закат солнца вручную... перекрывать из userspace это не 
получится.. а вот если бы кто-то сделал fakechroot на уровне ядра.. это 
было бы интересно. Но в твоём случае это скорее всего не поможет.

Rgds,
Rider

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Alexander Bokovoy]

Anton Farygin пишет:
> Странностей там хоть отбавляй.
> 
> Кстати, если ты последний раз смотрел его достаточно давно - попробуй
>  ещё раз. Я в течении последнего года добавил в него некоторое 
> количество не перекрытых ранее операций.
Я последний раз использовал scratchbox две недели назад, так что это
все-таки не твоя версия. Но она использует fakechroot из Debian.

См. http://samba.org/~ab/sambaxp-embedding-samba4.{odp,pdf}

> Кстати, в debian fackechroot полностью переписали, может быть список 
> перекрытых операций там более полон. Но в любом случае - это всё 
> выглядит как закат солнца вручную... перекрывать из userspace это не 
> получится.. а вот если бы кто-то сделал fakechroot на уровне ядра.. 
> это было бы интересно. Но в твоём случае это скорее всего не поможет.
> 
> 
Именно. Проблема в том, что такое перекрытие становится сильно завязано
на конкретную версию glibc и все -- пиши-пропало. Эта гонка хороша в
рамках одного дистрибутива, а для отдельных проектов такой вариант плохо
подходит.

Неуступчивость Дреппера можно понять...

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Anton Farygin]

Alexey Tourbin wrote:
> On Fri, May 12, 2006 at 11:08:46PM +0400, Alexander Bokovoy wrote:
>> Интересная дискуссия по поводу того, как делать "перекрытия" файловых 
>> операций для glibc. В свете ближнего и среднего будущего о smbsh и 
>> аналогах, похоже, придется забыть. Все же, autofs/automount более 
>> грамотный подход.
> 
> Дискуссию пока не осилил.
> Тем не менее хочу обратить внимание на plasticfs.

Который насколько я помню помер именно по этим же причинам.

Rgds,
Rider

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Alexander Bokovoy]

Alexey Tourbin пишет:
> On Fri, May 12, 2006 at 11:08:46PM +0400, Alexander Bokovoy wrote:
>> Интересная дискуссия по поводу того, как делать "перекрытия" 
>> файловых операций для glibc. В свете ближнего и среднего будущего о
>>  smbsh и аналогах, похоже, придется забыть. Все же,
>> autofs/automount более грамотный подход.
> 
> Дискуссию пока не осилил. Тем не менее хочу обратить внимание на 
> plasticfs.
Там тоже проблема с glibc (из glibc_hack(3) из plasticfs) и способ ее 
решения хуже:

The GNU C Library, glibc, has some features in version 2.2 and later
which make PlasticFS cease to work correctly. These features ensure that
the libc.so DSO loads as fast as possible,to the benefit of all
applications. This is accomplished by using a hidden PLT.

This is the default configuration of the GNU C Library. For PlasticFS to
work correctly, you need a version of libc.so without the hidden PLT.

To build a version of libc.so without the hidden PLT, you need
to have the sources for the exact version of the GNU C Library on
your system.


-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] [Fwd: [(nowhere)] fopen() calls __open]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Fri, May 12, 2006 at 11:08:46PM +0400, Alexander Bokovoy wrote:
> Интересная дискуссия по поводу того, как делать "перекрытия" файловых 
> операций для glibc. В свете ближнего и среднего будущего о smbsh и 
> аналогах, похоже, придется забыть. Все же, autofs/automount более 
> грамотный подход.

Это скорее не дискуссия, а FAQ.

> Date: Thu, 27 Apr 2006 10:43:08 -0700
> From: Ulrich Drepper <drepper@redhat.com>
> To: Derrell.Lipman@UnwiredUniverse.com
> CC: libc-alpha@sourceware.org
> Subject: Re: fopen() calls __open()
> Message-ID: <445102AC.5090505@redhat.com>
> References: <vesvx8jj.fsf@oberon-mail.internal> <4450F946.6030909@redhat.com>
> 	<8xprx810.fsf@oberon-mail.internal>
> MIME-Version: 1.0
> Content-Type: multipart/signed; boundary="=======-=-="
> 
> --=======-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
> 
> Derrell.Lipman@UnwiredUniverse.com wrote:
> > I'm a bit confused as to why certain functions are weak and allowed to be
> > overridden (e.g. open, __open)
> 
> Forget about weak.  The is no difference in the treatment of weak and
> strong symbols when they are defined in DSOs.  They are all the same.
> The aspect interesting for you is exported or not.  No internal libc
> call except those to the malloc functions references names which are
> exported.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]