[samba] обновление до 3.0.25

[Alexander Bokovoy]

Artem Zolochevskiy пишет:
>> И для каждого пользователя есть соответствующий пользователь в 
>> системе? Если так, то надо использовать винбайнд в том режиме, как
>>  это описано в idmap_nss(8).
> 
> да никак не хранятся. этож security = share да guest ok = yes или я 
> что-то недопонимаю. По крайней мере раньше работало :-)
Все, понял. Guest OK = yes тут не при чем, ведь нет guest only = yes :-)

В конечном итоге какой-то конкретный системный пользователь все равно
должен быть использован, а для этого преобразование от этого guest-а к
системному каким-то образом должно быть выполнено. Этим преобразованием
занимается winbind, который надо соответственно настроить, даже в режиме
security = share.

Если бы был guest only = yes, то все, что описано ниже, сразу бы
игнорировалось и рассматривался бы только guest user в качестве
пользователя, который должен участвовать "в процессе". В противном
случае, мы (smbd) не знает, какой системный пользователь соответствует
пришедшему извне и просит выполнить это преобразование winbindd. А у
того не описана стратегия преобразования и он говорит, что такого
пользователя нет.

Из документации (много):
When clients connect to a share level security server they need not log
onto the server with a valid username and password before attempting to
connect to a shared resource (although modern clients such as Windows 95
/98 and Windows NT will send a logon request with a username but no
password when talking to a security = share server). Instead, the
clients send authentication information (passwords) on a per-share
basis, at the time they attempt to connect to that share.

Note that smbd ALWAYS uses a valid UNIX user to act on behalf of the
client, even in security = share level security.

As clients are not required to send a username to the server
in share level security, smbd uses several techniques to determine the
correct UNIX user to use on behalf of the client.

A list of possible UNIX usernames to match with the given client
password is constructed using the following methods :

	If the guest only parameter is set, then all the other stages are
missed and only the guest account username is checked.

	Is a username is sent with the share connection request,
then this username (after mapping - see username map), is added as a
potential username.

	If the client did a previous logon request (the SessionSetup SMB call)
then the username sent in this SMB will be added as a potential
username.

	The name of the service the client requested is added as a
potential username. The NetBIOS name of the client is added to the list
as a potential username.

	Any users on the user list are added as potential usernames.

	If the guest only parameter is not set, then this list is then tried
with the supplied password. The first user for whom the password matches
will be used as the UNIX user.

	If the guest only parameter is set, or no username can be determined
then if the share is marked as available to the           guest account,
then this guest user will be used, otherwise
access is denied.

Note that it can be very confusing in share-level security as to which
UNIX username will eventually be used in granting access.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/