форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"запрет доступа к файлу в Unix"
Сообщение от Investigator on 21-Дек-03, 18:25  (MSK)
возможно ли в unix (конкретно в соларис спарк) запретить программно доступ к файлу из других процессов ? как это делается, есть ли, например, какие-либо виды специальных локов ?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "запрет доступа к файлу в Unix"
Сообщение от scum on 22-Дек-03, 16:24  (MSK)
Есть, конечно. Насколько я помню, этот момент еще в POSIX описан, называется принудительным блокированием (exclusive lock). Начни поиски с man flock (3 секция). Хотя лучше полистать "man pages section 3: Basic Library Functions" лежит он на docs.sun.com и называется 816-0213.pdf Могу привести кусок оттуда All the stdio functions are safe unless they have the _unlocked suffix. Each FILE pointer has its own lock to guarantee that only one thread can access it. In the case that output needs to be synchronized, the lock for the FILE pointer can be acquired before performing a series of stdio operations. For example: FILE iop; flockfile(iop); fprintf(iop, "hello "); fprintf(iop, "world); fputc(iop, ’a’); funlockfile(iop); will print everything out together, blocking other threads that might want to write to the same file between calls to fprintf(). An unlocked interface is available in case performace is an issue. For example: flockfile(iop); while (!feof(iop)) { *c++ = getc_unlocked(iop); } funlockfile(iop);
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "запрет доступа к файлу в Unix"
	Сообщение от Investigator on 22-Дек-03, 23:33  (MSK)
	Нужен аналог того, как это сделано в виндах (т.е. другой процесс не имеет никакого доступа - не может ни удалить ни открыть файл). Безотносительно того, пользуется он этими функциями или нет. В качестве другого процесса может выступать любой сторонний файл-менеджер или текстовый редактор. >Есть, конечно. Насколько я помню, этот момент еще в POSIX описан, называется >принудительным блокированием (exclusive lock). Начни поиски с man flock (3 секция). >Хотя лучше полистать "man pages section 3: Basic Library Functions" лежит >он на docs.sun.com и называется 816-0213.pdf >Могу привести кусок оттуда > >All the stdio functions are safe unless they have the _unlocked suffix. >Each FILE pointer has its own lock to guarantee that only >one thread can access it. In the case that output needs >to be synchronized, the lock for the FILE pointer can be >acquired before performing a series of stdio operations. For example: > >FILE iop; >flockfile(iop); >fprintf(iop, "hello "); >fprintf(iop, "world); >fputc(iop, ’a’); >funlockfile(iop); > >will print everything out together, blocking other threads that might want to >write to the same file between calls to fprintf(). > >An unlocked interface is available in case performace is an issue. For >example: > >flockfile(iop); >while (!feof(iop)) { >*c++ = getc_unlocked(iop); >} >funlockfile(iop);
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "запрет доступа к файлу в Unix"
	Сообщение от Leningrad on 23-Дек-03, 00:05  (MSK)
	man chmod книжку купи
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "запрет доступа к файлу в Unix"
	Сообщение от Макс Зиналь on 03-Янв-04, 20:02  (MSK)
	>Есть, конечно. Насколько я помню, этот момент еще в POSIX описан, >называется принудительным блокированием (exclusive lock). >Начни поиски с man flock (3 секция). Начали за здравие, хотя advisory locks, достижимые через flock(), имеют весьма косвенное отношение к вопросу, коий человек задал. Кто оный вызов не пользует, тот о существовании блокировки и не узнает. На то она и advisory. >Хотя лучше полистать "man pages section 3: Basic Library Functions" лежит >он на docs.sun.com и называется 816-0213.pdf >Могу привести кусок оттуда > >All the stdio functions are safe unless they have the _unlocked suffix. >Each FILE pointer has its own lock to guarantee that only >one thread can access it. In the case that output needs >to be synchronized, the lock for the FILE pointer can be >acquired before performing a series of stdio operations. For example: > >FILE iop; >flockfile(iop); >fprintf(iop, "hello "); >fprintf(iop, "world); >fputc(iop, ’a’); >funlockfile(iop); > >will print everything out together, blocking other threads that might >want to write to the same file between calls to fprintf(). > >An unlocked interface is available in case performace is an issue. For >example: > >flockfile(iop); >while (!feof(iop)) { >*c++ = getc_unlocked(iop); >} >funlockfile(iop); А Вы сами-то по Аглицки читаете? Разговор идёт о защите доступа к структурам, связанным с буферизованным вводом-выводом, в многопоточных программах. Слово "блокировка" здесь, конечно, присутствует, только она не на файл, а на структуру FILE и иже с нею. Аналогичных Виндовым блокировок доступа к файлам на системном уровне в чистой POSIX-системе, IMHO, не бывает. Их можно сэмулировать в собственном софте разными всякими способами, однако форсировать применение нововведённых программистом ограничений на доступ система не будет. Пониже тут кто-то неплохой вариант предложил - доступ к файлику прикрывать chmod()ом. Не без недостатков, впрочем, поскольку файлик нужно ещё и самому открыть. А если сначала открыть, а потом chmod(), то нет никакой гарантии, что кто-нибудь его тоже не откроет - в промежутке между open() и chmod(). Атомарности нету.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "запрет доступа к файлу в Unix"
	Сообщение от XMan on 03-Янв-04, 21:51  (MSK)
	В этом способе много недостатков. И он действительно будет самым настоящим костылем, если не существует ничего другого. На мой взгляд, такую штуку давно нужно было всунуть в ядро или библиотеки. Но правильнее в ядро :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "запрет доступа к файлу в Unix"
	Сообщение от Макс Зиналь on 04-Янв-04, 16:29  (MSK)
	>В этом способе много недостатков. И он действительно будет самым >настоящим костылем, >если не существует ничего другого. На мой взгляд, такую штуку давно >нужно было всунуть в ядро или библиотеки. Но правильнее в ядро >:) Мне, по-правде говоря, довольно трудно представить себе, _зачем_ нужен подобный механизм. Если собственный софт из множества процессов-потоков лезет в один и тот же файл, блокировку на прикладном уровне реализовать просто - хотя бы через тот же flock(). А как в Виндах и OpenVMS'е, намертво закрывать возможность открытия файла - для чего? От кого защищаться?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "запрет доступа к файлу в Unix"
	Сообщение от XMan on 04-Янв-04, 20:28  (MSK)
	А кто сказал, что в файл лезет только "собственный софт" ? А шаловливые ручки. Или tmpwatch какой-нибудь ? А тот же rpm при обновлении софта ? Кроме  того, существует понятие "гонок", вполне применимое к записи в файл. Пример такого состояния приводится в любой мало мальски нормальной книге по программированию (в том числе и под Unix). И наблюдать вместо вызова функции блокирования создание еще одного файла несколько неприятно. Живой пример - программа падает, файл лочки остается. Чего далеть ? Правильно - неоднозначность. Приходится еще выдумывать чего-то этакого, чтобы небыло неоднозначностей. Заметьте - неспроста в SQL существует понятие транзакции :) Мертвое зависание - это кривость обработки. Ядро должно отслеживать кто и как чего открыл (всё равно за файловыми дескрипторами следит оно) и в случае завершения процесса выполнять соответствующие действия.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "запрет доступа к файлу в Unix"
	Сообщение от Макс Зиналь on 05-Янв-04, 19:42  (MSK)
	>А кто сказал, что в файл лезет только "собственный софт" ? А >шаловливые ручки. Или tmpwatch какой-нибудь ? А тот же rpm при >обновлении софта ? От шаловливых ручек ничего на свете не спасает. А tmpwatch есть крайне специфическая программа, которая (IMHO) предназначена в основном для админов-садистов в университетских сетках. Ах, давно не было доступа к файлику? В печку его, в печку! Тут админ как раз весьма доволен должен быть - никакими силами "лишний" файлик на месте не останется :). При обновлении софта отсутствие блокировок, на мой взгляд, сущее благо. Софт себе крутится, тормозить его не надо, все библиотеки да бинарники заменил - при следующем рестарте подымется уже свежачок. >Кроме  того, существует понятие "гонок", вполне применимое к записи >в файл. Пример такого состояния приводится в любой мало мальски >нормальной книге по программированию (в том числе и под Unix). И >наблюдать вместо вызова функции блокирования создание еще одного файла >несколько неприятно. Живой пример - программа падает, файл лочки >остается. Чего далеть ? Правильно - неоднозначность. >Приходится еще выдумывать чего-то этакого, чтобы небыло неоднозначностей. >Заметьте - неспроста в SQL существует понятие транзакции :) > Просто каждому функционалу свое время и место. Факт "процесс X открыл файл Y" никак не связан с фактом "нельзя лазить в файл Y". А в лочный файлик можно ведь и pid записать. Или вообще трубочку применить (открывается - блокировка живая, нет - мертвая). >Мертвое зависание - это кривость обработки. Ядро должно отслеживать >кто и как чего открыл (всё равно за файловыми дескрипторами следит оно) >и в случае завершения процесса выполнять соответствующие действия. Собственно, какие? Файлик оно и так закрывает. Блокировки снимать? UNIX-way, на мой взгляд, здесь состоял бы в реализации на _прикладном_ уровне серверного приложения, контролирующего оные блокировки. С возможностью проверки "а жив ли мальчик", т.е. владелец блокировки. Ядро-то тут зачем? Разве что для стандартизации API - дак ведь этого и другими способами достичь можно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "запрет доступа к файлу в Unix"
	Сообщение от XMan on 05-Янв-04, 22:33  (MSK)
	> Софт себе крутится, тормозить его не надо, все библиотеки да бинарники заменил - при следующем рестарте подымется уже свежачок. Угу. А никогда не попадал на обновление библиотеки во время обращения к оной ? Очень интересно регистры вываливаются :) > Факт "процесс X открыл файл Y" никак не связан с фактом "нельзя лазить в файл Y". Связан, если открывший процесс хочет быть уверен, что запишет в него именно то, что он туда послал, а не то, что получилось при смешении нескольких потоков. Кому такая каша нужна будет ? > А в лочный файлик можно ведь и pid записать. Угу. Представляем 2 процесса. Один записал туда свой пид, второй смотрит - не он, значит ждем, пока не освободится файл. Первый процесс падает. Вопрос - как долго будет смотреть второй процесс в файл ? > Разве что для стандартизации API - дак ведь этого и другими способами достичь можно. Всего можно достичь другими способами. Зачем тогда колесо использовать ? Давайте таскать всё на носилках :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "запрет доступа к файлу в Unix"
	Сообщение от Макс Зиналь on 06-Янв-04, 20:55  (MSK)
	>Угу. А никогда не попадал на обновление библиотеки во время >обращения к оной ? Очень интересно регистры вываливаются :) > Интересно, под какой такой ОСью? В Солярке, насколько я в курсе и насколько мне мой собственный опыт по наступанию на грабли подсказывает, замещённый бинарник реально удаляется с диска только _после_ закрытия всех программ, его использующих. И символы они таскают именно из такой старой копии. Что касается собственно непродолжительного момента самого обновления, так и хрен с ним, по крупному-то. Ненадолго же. >Связан, если открывший процесс хочет быть уверен, что запишет в него >именно то, что он туда послал, а не то, что получилось при >смешении нескольких потоков. Кому такая каша нужна будет ? > Если он файлик целиком формирует, то открывает он его с замещением. А если нет, то прямой вопрос к разработчику - а чего он имел в виду? Случай с эксклюзивной блокировкой не только не единственный, но даже и не самый часто встречающийся. При аккуратном обращении в системе _без_ обязательных блокировок, форсируемых ядром, можно достичь целого ряда весьма удобных эффектов, невозможных в случае, когда ядро насильственно запрещает ряд семантически вполне допустимых действий. Ибо отличить корректные действия от некорректных при "форсированной" системе блокировок можно лишь с некоторой степенью вероятности. >> А в лочный файлик можно ведь и pid записать. > >Угу. Представляем 2 процесса. Один записал туда свой пид, второй >смотрит - не он, значит ждем, пока не освободится файл. Первый >процесс падает. Вопрос - как долго будет смотреть второй процесс >в файл ? > Проверка, например, через /proc: владелец блокировки умер - можно сооружать свою собственную. > >> Разве что для стандартизации API - дак ведь этого и другими способами достичь можно. > >Всего можно достичь другими способами. Зачем тогда колесо использовать ? >Давайте таскать всё на носилках :) Давайте все возможные базовые алгоритмы в ядро запихаем и кучу syscall()ов наделаем. Тогда прикладные программы будут из одних обращений к сверхумному ядру и состоять. Только вот ядро глючноватое будет. Примерно как в Виндах :). Ибо вылизать сложное ядро ОС так, как в своё время вылизали OpenVMS, в наше время невозможно по экономическим и политическим причинам ;-).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "запрет доступа к файлу в Unix"
	Сообщение от XMan on 06-Янв-04, 23:59  (MSK)
	> Интересно, под какой такой ОСью? Да под каким-то линухом. Я там налету менял NSS-модуль для glibc и периодически наблюдал регистры, но без падений системы :) > Если он файлик целиком формирует, то открывает он его с замещением. Берем 2 процесса. Они открывают один файл с замещением и начинают в него активно писать каждый своё. Что получится в результате ? > Проверка, например, через /proc: владелец блокировки умер - можно сооружать свою собственную. А если блокировка поставлена удаленным процессом по NFS ? В какой proc смотреть ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "запрет доступа к файлу в Unix"
	Сообщение от Макс Зиналь on 07-Янв-04, 19:18  (MSK)
	>> Если он файлик целиком формирует, то открывает он его с замещением. > >Берем 2 процесса. Они открывают один файл с замещением и начинают в >него активно писать каждый своё. Что получится в результате ? > IMO, результат работы того, который "успел вторым" :) >> Проверка, например, через /proc: владелец блокировки умер - можно >сооружать свою собственную. > >А если блокировка поставлена удаленным процессом по NFS ? В какой proc >смотреть ? А вот тут ядрышко вообще ни при чём. NFS - протокол специфический, для повышения надёжности все операции в нём безконтекстные. То бишь сервер не запоминает состояния клиентов. Так что какие где файлы и кем открыты, протокол отследить не позволяет, в отличие от SMB/CIFS. Так что как раз вот в этом случае ну никуда не деться от мааленького такого прикладного сервачка, отслеживающего состояние нужных блокировок.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "запрет доступа к файлу в Unix"
	Сообщение от XMan on 07-Янв-04, 19:40  (MSK)
	> IMO, результат работы того, который "успел вторым" :) А первый об этом как узнает ? Кстати, не потому ли сейчас народ всерьёз думает отходить от файловой системы как таковой и двигаться в сторону базы данных вместо нее ? Хотя фс - это и так своеобразная база данных :) > А вот тут ядрышко вообще ни при чём. NFS - протокол специфический, для повышения надёжности все операции в нём безконтекстные. Ну, ядро-то как раз при чем. Не спроста же в нем модуль отдельный сделан под NFS :) > Так что как раз вот в этом случае ну никуда не деться от мааленького такого прикладного сервачка, отслеживающего состояние нужных блокировок. Вот вот... Я ж и говорю - придумывать велосипед :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "Если говорить о понятиях то Solaris - это не Unix (+)"
Сообщение от Арлекин on 06-Янв-04, 09:24  (MSK)
Соляра (HW:SPARC, Intel, MIPS ... - значения не имеет), версий 2.х, базируется на ядре System V4.2, и поэтому юниксом как таковым не является. Юниксы: IBM AIX (и то ветвь OSF/1), SCO UNIX ("скотина"),SGI IRIX ("ириска"). "Генеалогию" можно посмотреть тут: http://vap.org.ru/daemonix/03.shtml Короче: в ядре System V4.2 НЕТ исключающих блокировок. Есть только рекомендуемые. Т.е. блокировку файла на уровне ОС сделать невозможно. Только в scope прикладного софта. Пример - ORACLE, изнутри БД файлы блокируются, но снаружи можно творить с ними все что угодно.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "Если говорить о понятиях то Solaris - это не Unix (+)"
	Сообщение от Murr on 09-Янв-04, 22:07  (MSK)
	The mandatory locking scheme is defined by the System V Interface Definition (SVID) Version 3. Solaris - как раз классический UNIX потому что основан на коде System V (true UNIX). На нем же основан IBM AIX (а не OSF/1).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.