From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4464E884.4000207@altlinux.com> Date: Fri, 12 May 2006 23:56:52 +0400 From: Anton Farygin Organization: ALT Linux Ltd. User-Agent: Thunderbird 1.5.0.2 (X11/20060502) MIME-Version: 1.0 To: ALT Devel discussion list References: <4464DD3E.6040203@altlinux.org> <4464E0B1.4070708@altlinux.com> <4464E5CD.6070100@altlinux.org> In-Reply-To: <4464E5CD.6070100@altlinux.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] [Fwd: [(nowhere)] fopen() calls __open] X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 19:56:35 -0000 Archived-At: List-Archive: List-Post: 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