ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Evgeny Sinelnikov <sin@altlinux.ru>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] thunar-shares-plugin
Date: Sat, 21 Feb 2009 07:54:19 +0300
Message-ID: <921f6bb40902202054h679b5d24hd3ee9c7fca1907f9@mail.gmail.com> (raw)
In-Reply-To: <6062a6e60902201809n565c46efy45d5bcc2a7accad7@mail.gmail.com>

21 февраля 2009 г. 5:09 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> 2009/2/20 Денис Смирнов <mithraen@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)

  reply	other threads:[~2009-02-21  4:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19 18:49 ` Led
2009-02-20  5:06     ` REAL
2009-02-20  6:04     ` Alexander Bokovoy
2009-02-20 10:03         ` Денис Смирнов
2009-02-20 11:27           ` Alexander Bokovoy
2009-02-20 15:12             ` Денис Смирнов
2009-02-20 20:43                 ` Led
2009-02-21  2:09               ` Alexander Bokovoy
2009-02-21  4:54                 ` Evgeny Sinelnikov [this message]
2009-02-21 11:15                   ` Alexey I. Froloff
2009-02-21 16:22                     ` Денис Смирнов
2009-02-22 13:07                   ` Mikhail Gusarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=921f6bb40902202054h679b5d24hd3ee9c7fca1907f9@mail.gmail.com \
    --to=sin@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git