[devel] thunar-shares-plugin

[Evgeny Sinelnikov]

21 февраля 2009 г. 5:09 пользователь Alexander Bokovoy
<ab at altlinux.org> написал:
> 2009/2/20 Денис Смирнов <mithraen at altlinux.ru>:
>> On Fri, Feb 20, 2009 at 01:27:53PM +0200, Alexander Bokovoy wrote:
>>>> Не проверял, но 'force user' здесь не может помочь?
>> AB> user shares - это средство для решения совсем других задач. Типичный
>> AB> случай применения -- рабочая станция, права администрирования которой
>> AB> не принадлежат работающему на ней сотруднику, однако сотруднику
>> AB> необходимо предоставить возможность раздачи своих ресурсов. Для этого
>> AB> правила настройки таких ресурсов размещаются однажды администратором,
>> AB> а сотрудник создает "ресурсы" в заранее определенном месте. В этом
>> AB> случае Самба показывает их как "полноценные ресурсы", неотличимые от
>> AB> определенных в системе. Но и сотрудник не имеет возможности изменить
>> AB> системные определения.
>>
>> Тогда может быть лучше не делать их внутри $HOME? У нас в офисе для этого
>> используется /var/lib/$groupname, например, хотя это кривовато.
> Это все определяется администратором. Поэтому я не хочу задавать
> какую-либо конкретику "по умолчанию" в основном пакете. В чистом виде
> работа для настроечного модуля.
>

Тем не менее вариантов ограниченное число, если нет чёткого
предложения, то должны быть хотя бы варианты. Я думаю, что для $HOME
вариантов три:

1) Приводимый выше force user в того пользователя, чей домашний
каталог используется. ИМХО, для работы в хомяке подходит больше всего.
Компромисс с этим вариантом состоит в том, что нельзя разделить
внутренние права общего каталога для разных подключившихся
пользователей на разные файлы.... Этот недостаток является
преимуществом - таких возможностей для общего каталога в домашнем
каталоге и не нужно...

2) 710 + force group. Не имеет недостатка связанного с разными правами
для разных пользователей, разграничивает доступ по группе, но имеет
большой недостаток, связанный с возможностью создания каталогов с
файлами принадлежащих пользователю отличному от держателя домашнего
каталога... Это приводит к тому, что в домашнем каталоге могут
появится подкаталоги, которые не доступны владельцу домашнего
каталога, причём он их даже удалить не сможет (ни локально, ни по
сети)...

3) 711 или 701. Второй вариант странен из-за того, что может не
работать по не очевидным причинам - нужный пользователь окажется в
группе, которая задана для домашнего каталога. До тех пор пока это
локальные пользователи всё вроде нормально, ибо из они вроде как
создаются каждый со своей группой. А вот пользователи из AD, например,
имеют обычно одну и ту же главную группу - пользователи домена,
которую 701 отрезает... Тем не менее эти варианты одинаково направлены
на одну и ту же цель - предоставить общий каталог для всех. Но,
учитывая, что недостатки связанные с вариантом 2 можно возвести в
степень при использовании групп, поскольку понять почему кому-то
что-то нельзя будет весьма не просто...

Если кто-нибудь подскажет, как обойти проблемы вариантов 2 и 3 с
помощью пресловутых nested groups, буду крайне благодарен. Пока что я
думаю, что вариант 1 является жизнеспособным, вариант 2 является
ограниченно жизнеспособным, вариант 3 - ещё менее жизнеспособным.

-- 
Sin (Sinelnikov Evgeny)