FreeBSD поражает

Персональный блог одноименного форумчанина. Человека и парохода, не побоюсь этого сравнения :)

Модератор: tyomitch

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

FreeBSD поражает

Сообщение tyomitch » 02.06.2006 (Пт) 16:29

Это не пост, а мини-заметочка по свежим впечатлениям.

Все знают, как *нихоиды любят возможность подмонтировать диск в любое место файловой системы. Причём не обязательно в пустую папку, как в Windows NT -- можно и в полную. При этом предыдущее содержимое папки "заметается под ковёр":
man 2 mount писал(а):The contents of the file system become available through the new mount point dir. Any files in dir at the time of a successful mount are swept under the carpet so to speak, and are unavailable until the file system is unmounted.

Оказывается, заметаются под ковёр не только бывшие в папке файлы, но и её разрешения -- на то время, пока в папку подмонтирован диск, старые разрешения на папку "забываются", а новые берутся, наверное, откуда-то из заголовка подмонтированной файловой системы.

Стандартными способами доступ как к родным файлам, так и к родным разрешениям папки--точки монтирования, казалось бы, не получить. Ан нет -- fts_read(3), используемая для обхода иерархии папок, по-видимому, работает с ФС на низком уровне, и поэтому использует именно родные разрешения папок. Эту функцию используют find(1), ls(1) с ключом -R, и все остальные программы рекурсивного обхода папок.

Итак, что мы получаем, когда у нас, так же как у меня сегодня, диск с разрешениями 777 оказывается подмонтированным в папку с разрешениями 000?
* зайти в папку -- можно;
* получить листинг внутри папки -- можно;
* читать и писать файлы внутри папки -- можно;
* получать рекурсивный листинг из снаружи папки -- нельзя. Вылезает ошибка "fts_read: Permission denied", при том, что видимые разрешения всюду -- 777.
Единственный выход -- отмонтировать диск, поменять разрешения на папку, и подмонтировать диск снова.

До сих пор не могу понять -- это баг или фича? Ответ на этот вопрос пообещали дать в Problem Report 33235, но оттуда неизменно приходит отлуп "The PR database is currently busy; please try your query again."
Изображение

Amed
Алфизик
Алфизик
 
Сообщения: 5346
Зарегистрирован: 09.03.2003 (Вс) 9:26

Сообщение Amed » 02.06.2006 (Пт) 16:34

http://www.freebsd.org писал(а):Problem Report bin/33235 : find terminates with "find: fts_read: Permission denied"
find terminates with "find: fts_read: Permission denied"

Confidential
no
Severity
serious
Priority
medium
Responsible
freebsd-bugs@FreeBSD.org
State
closed
Class
sw-bug
Submitter-Id
current-users
Arrival-Date
Thu Dec 27 02:10:00 PST 2001
Closed-Date
Sat Jul 13 15:16:15 PDT 2002
Last-Modified
Sat Jul 13 15:16:15 PDT 2002
Originator
Heikki Suonsivu <hsu@bbnetworks.net>
Release
FreeBSD 4.4-STABLE i386
Organization
bbnetworks
Environment
System: FreeBSD katiska.runkoverkot.net 4.4-STABLE FreeBSD 4.4-STABLE #1: Fri Oct 12 03:29:04 EEST 2001 hsu@katiska.runkoverkot.net:/usr/obj/usr/src/sys/CAT i386

Stable from october. I think the problem has been around for a while,
but I had had no time to figure out why locate database seemed to be empty.

Description
Symtom is that locate update does not include all files in the
database, because the find terminates early.

How-To-Repeat
On one of my hosts this will terminate when run as nobody:

find -s / \! \( -fstype ufs \) -prune -or -path /tmp -prune -or -path /usr/tmp
-prune -or -path /var/tmp -prune -or -print
...
/xx/sorted/2001/12/13/image_2001_1213_142409_01.jpg
/xx/sorted/2001/12/13/image_2001_1213_142418_01.jpg
/xx/sorted/2001/12/13/imagfind: fts_read: Permission denied
e_2001_1213_142430_01.jpg
/xx/sorted/2001/12/13/image_2001_1213_142436_01.jpg
/xx/sorted/2001/12/14
/xx/sorted/2001/12/14/image_2001_1214_050908_01.jpg
/xx/sorted/2001/12/14/image_2001_1214_050910_01.jpg
/xx/sorted/2001/12/14/image_2001_1214_050923_01.jpg

The command is what locate.updatedb uses. I found this when trying to
figure out why locate database did not contain some of the files which
certainly were there.

Fix
If -s is left out, find completes. Thus, workaround for
locate.updatedb problem is replacing -s with "| sort" after find, but
that is not particularly efficient. Find should not consider
permission denied a fatal error.

Audit-Trail
From: "Crist J . Clark" <cjc@FreeBSD.ORG>
To: Heikki Suonsivu <hsu@bbnetworks.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/33235: find terminates with "find: fts_read: Permission denied"
Date: Fri, 28 Dec 2001 00:31:58 -0800

On Thu, Dec 27, 2001 at 12:05:53PM +0200, Heikki Suonsivu wrote:
[snip]

> >How-To-Repeat:
>
> On one of my hosts this will terminate when run as nobody:
>
> find -s / \! \( -fstype ufs \) -prune -or -path /tmp -prune -or -path /usr/tmp
> -prune -or -path /var/tmp -prune -or -print
> ...
> /xx/sorted/2001/12/13/image_2001_1213_142409_01.jpg
> /xx/sorted/2001/12/13/image_2001_1213_142418_01.jpg
> /xx/sorted/2001/12/13/imagfind: fts_read: Permission denied
> e_2001_1213_142430_01.jpg
> /xx/sorted/2001/12/13/image_2001_1213_142436_01.jpg
> /xx/sorted/2001/12/14
> /xx/sorted/2001/12/14/image_2001_1214_050908_01.jpg
> /xx/sorted/2001/12/14/image_2001_1214_050910_01.jpg
> /xx/sorted/2001/12/14/image_2001_1214_050923_01.jpg
>
> The command is what locate.updatedb uses. I found this when trying to
> figure out why locate database did not contain some of the files which
> certainly were there.
>
> >Fix:
>
> If -s is left out, find completes. Thus, workaround for
> locate.updatedb problem is replacing -s with "| sort" after find, but
> that is not particularly efficient. Find should not consider
> permission denied a fatal error.

A "permission denied" is usually not a fatal error, but in this case,
the fts_read(3) call is getting the error, which shouldn't happen. I
_think_ I understand why this may be happening. When you use the '-s'
switch, there may be an attempt to compare a file name to one that we
cannot read... But I'm not sure how this could happen. Could you give
us a long listing of the portion of file hierarchy (both a little
before and after too) where you think this is failing?
--
"It's always funny until someone gets hurt. Then it's hilarious."

Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
State-Changed-From-To: open->closed
State-Changed-By: cjc
State-Changed-When: Sat Jul 13 15:15:58 PDT 2002
State-Changed-Why:
Feedback timeout.

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

Сообщение tyomitch » 03.06.2006 (Сб) 11:55

Послал им Problem Report 98414.
Посмотрим, что ответят.
Изображение

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

Сообщение tyomitch » 05.10.2006 (Чт) 20:46

Гы-гы. Четыре месяца багу. Ноль внимания разработчиков.
Кто-нибудь может протестить -- в свежевышедших 6.1 / 5.5 он проявляется?
Изображение

Денис Победря
Мегобойанист
Мегобойанист
 
Сообщения: 1037
Зарегистрирован: 03.01.2005 (Пн) 21:29
Откуда: Из Москвы

Сообщение Денис Победря » 06.10.2006 (Пт) 14:59

Это только в бсд такое наблюдается?
[Место cдаётся]


Вернуться в Tyomitch

Кто сейчас на конференции

Сейчас этот форум просматривают: Google-бот и гости: 1

    TopList