FreeBSD поражает

[tyomitch]

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

Все знают, как *нихоиды любят возможность подмонтировать диск в любое место файловой системы. Причём не обязательно в пустую папку, как в Windows NT -- можно и в полную. При этом предыдущее содержимое папки "заметается под ковёр":

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]

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]

Послал им Problem Report 98414.
Посмотрим, что ответят.

[tyomitch]

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

[Денис Победря]

Это только в бсд такое наблюдается?