Bug 19199 - Добавить upcall + pam_smbpass + ...
: Добавить upcall + pam_smbpass + ...
Status: CLOSED FIXED
: Branch 5.0
(All bugs in Branch 5.0/samba)
: unspecified
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-03-16 16:53 by
Modified: 2009-04-03 16:31 (History)


Attachments
бэкпорт cifs.upcall (21.85 KB, patch)
2009-03-16 16:53, Andriy Stepanov (stanv)
no flags Details | Diff
ip-to-hostname (2.94 KB, application/octet-stream)
2009-03-16 17:02, Andriy Stepanov (stanv)
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-03-16 16:53:34
Created an attachment (id=3373) [details]
бэкпорт cifs.upcall

1.
В версии 3.0 нету хелпера для ядра,
для монтирования CIFS посредством kerberos уантификации.
Патч взят с 3.2 (бэкпорт cifs.upcall).

2.
Очень нужен pam модуль pam_smbpass.so (--with-pam_smbpass)

3.
Желательно подумать как добавлять в /etc/request-key.conf
строчки типа:
create  cifs.spnego *           *               /usr/sbin/cifs.upcall %k
create  dns_resolver *          *               /usr/sbin/cifs.upcall %k

4. AB@: если можешь дерни kukks@samba.org или кого-то еще.
Вот кратко суть проблемы:

About UID/GID + cifs.mount + sec=krb5

The problem is that:

[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
-osec=krb5
parsing options: sec=krb5

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,pass=,ver=1,sec=krb5,uid=500,gid=500

[stanv@stanv vid3]$ l share2
итого 1028
drwxr-xr-x 2 stanv stanv    0 Мар 12 15:51 for_mumu/
drwxr-xr-x 4 stanv stanv    0 Мар 12 15:46 ./
drwxr-xr-x 4 stanv stanv 4096 Мар 12 15:42 ../
drwxr-xr-x 2 stanv stanv    0 Мар 11 15:49 for_stanv/
-rw-r--r-- 1 stanv stanv    4 Мар  5 20:28 123

uid=500,gid=500  are passed down to kernel

all files owned by me
------- Comment #1 From 2009-03-16 16:57:07 -------
Пункты 1-4 нужны для ветки 5.0
------- Comment #2 From 2009-03-16 17:02:36 -------
Created an attachment (id=3374) [details]
ip-to-hostname

Патч взят отсюда: http://patchwork.kernel.org/patch/4594/
Не уверен что он нам нужен.
У меня и без него работает.
------- Comment #3 From 2009-03-16 17:30:32 -------
Пункт 4.0 более детально.

В smb.conf есть опция:

Default: unix extensions = yes

# testparm -v -s 2>/dev/null | grep -i 'unix extensions'
        unix extensions = Yes

Т.е. на Samba-сервер включили unix extensions.

Парочка цитат из MOUNT.CIFS(8) о параметре: uid=arg

sets the uid that will own all files on the mounted filesystem
For mounts to servers which do support the CIFS Unix extensions

If the server and client are in the same domain (e.g. running winbind or
nss_ldap) and the server supports the Unix Extensions then the uid and gid can
be retrieved from the server (and uid and gid would not have to be specifed on
the mount.

For servers which do not support the CIFS Unix extensions, the default uid (and
gid) returned on lookup of existing files will be the uid (gid) of the person
who executed the mount (root, except when mount.cifs is configured setuid for
user mounts) unless the "uid=" (gid) mount option is specified. 


Т.е. если мы не указываем явно опцию UID: то при монтировании CIFS ресурса мы
будем видеть настоящие UID (как на стороное сервера).

Убедимся в этом:

$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
Password: 

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,pass=q1,ver=1

$ find share2 -printf '%u(%U) %g(%G) %p\n'
root(0) root(0) share2
mumu(501) camera(501) share2/for_mumu
mumu(501) camera(501) share2/for_mumu/dfadfsdf
mumu(501) camera(501) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
root(0) root(0) share2/123

т.е. в смонтированом ресурсе мы видим ID владельцев, каковы они являются на
сервере.

Теперь смонтируем через Kereberos:
$ kinit 
Password for stanv@MALTA.ALTLINUX.RU: 
[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
-osec=krb5,guest
parsing options: sec=krb5,guest

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,ver=1,sec=krb5,guest,uid=500,gid=500 

$ find share2 -printf '%u(%U) %g(%G) %p\n'
stanv(500) stanv(500) share2
stanv(500) stanv(500) share2/for_mumu
stanv(500) stanv(500) share2/for_mumu/dfadfsdf
stanv(500) stanv(500) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
stanv(500) stanv(500) share2/123

Как видим везде владелец - я. Но записать я не могу в папку share2/for_mumu

Это все от того что ядру передается параметр: guest,uid=500,gid=500 
о котором говорилось выше.
------- Comment #4 From 2009-03-17 10:09:58 -------
Еще один интересный факт (отношения к Kerberos не имеет).

Если задать свое же имя ($USER) user=arg (specifies the username to connect
as), также происходит нарушение прав.

Без задания user (права как на сервере):

[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
Password: 

mount.cifs kernel mount options 
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,pass=q1,ver=1 
[stanv@stanv vid3]$ find share2 -printf '%u(%U) %g(%G) %p\n'
root(0) root(0) share2
mumu(501) camera(501) share2/for_mumu
mumu(501) camera(501) share2/for_mumu/dfadfsdf
mumu(501) camera(501) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
root(0) root(0) share2/123

[stanv@stanv vid3]$ cifsumount share2

С заданием своего же имени:

[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
-ousername=stanv
parsing options: username=stanv
Password: 

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,pass=q1,ver=1,username=stanv,uid=500,gid=500 
[stanv@stanv vid3]$ find share2 -printf '%u(%U) %g(%G) %p\n'
stanv(500) stanv(500) share2
stanv(500) stanv(500) share2/for_mumu
stanv(500) stanv(500) share2/for_mumu/dfadfsdf
stanv(500) stanv(500) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
stanv(500) stanv(500) share2/123
------- Comment #5 From 2009-03-17 16:41:48 -------
К пунку 4.
https://bugzilla.samba.org/show_bug.cgi?id=6194

К Пункту 1.
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/236830
------- Comment #6 From 2009-03-30 02:27:42 -------
В 3.0.33-alt2 сделал поддержку cifs.upcall, немного не так, как в предлагаемом
патче от Debian, потому что в Debian сделали больше вмешательств, чем
требовалось.

Пункт 2 исправлять не буду. Пункт 2 представляет собой неверное решение общей
проблемы -- используйте winbindd/pam_winbind, как это рекомендовано в
документации уже несколько лет. pam_smbpass более не поддерживается.

Пункт 4 исправлять в рамках 3.0 не имеет смысла. Вернемся к нему в 3.3-3.4.
------- Comment #7 From 2009-04-03 16:31:11 -------
Irssi: Join to #samba-technical was synced in 1 secs

15:47 < stanv> hello
15:48 < stanv> how about: https://bugzilla.samba.org/show_bug.cgi?id=6194
15:48 < stanv> ??
15:51 < vl> stanv: You should talk to Jeff Layton
15:51 < stanv> jlayton: 
15:51 < stanv> :))
15:52 -!- mdambrosio [n=mdambros@190.1.56.145] has joined #samba-technical
16:13  * jlayton looks
16:15 < jlayton> stanv: this is primarily because CIFS has a bazillion mount
options, but no one has given much thought about how they all work together
16:15  * jlayton stops bitching now
16:16 < jlayton> at one point, the uid/gid options didn't override the
ownership of files when unix extensions were enabled
16:16 < jlayton> but unix extensions are pretty broken anyway since they assume
that uid/gid are the same on client and server
16:17 < jlayton> not necessarily the case, of course
16:19 < kblin> jlayton: I agree. the whole concept of non-unique ids is broken
16:20 < kblin> I actually like SIDs
16:20 < jlayton> wanon and I discussed this a bit at connectathon
16:20 < jlayton> SID's don't exactly match either if the client and server are
in different domains too, correct?
16:21 < jlayton> s/exactly/necessarily/
16:21 <@idra> jlayton, they don't match at all, it's exactly the point of SIDs
:)
16:21 < jlayton> ahh
16:21 <@idra> jlayton, but usually client and server are in the same domain and
users should be "domain" users
16:22 <@idra> if you are a domain user you have a SID assigned by the domain
controller that is the same on every machine
16:22 < stanv> so, is it possible to find how to correct 6194 ?
16:23 < kblin> idra: technically that's the same as local accounts on the DC,
iirc :)
16:24 < kblin> jlayton: I'd very much welcome unique id support in the kernel,
but I somehow doubt that's going to happen
16:24 <@idra> kblin, does it matter? :)
16:25 < kblin> idra: not really, apart form making life easier when
implementing local accounts :)
16:25 <@idra> we would just need 128bit IDs
16:25 < jlayton> stanv: not trivially
16:25 <@idra> and possibly finally disacrd the difference between uids and gids
16:26 <@idra> jlayton, stanv the problem is this
16:26 <@idra> you could think that it is trivial to do a 1-1 substitution of
your requested uid and gid with the server's user uid and gid
16:26 <@idra> it would be a 2 elements table conversion right ?
16:27 <@idra> except that you have also all those other users ids
16:27 < kblin> idra: yeah. whatever.. I'm just afraid that some genious would
still give the first user on every system the same ID if they were just 128 bit
numbers
16:27 <@idra> assume you want to change ownership, how do you do it? what if
another user uid is the same of the requested uid ?
16:28 <@idra> we move quickly to having also to map to something else all other
user's and group's ids on the server
16:28 <@idra> kblin, of course they would
16:28 <@idra> kblin, I have no hope most people would understand :)
16:29 < kblin> which is why a fixed, more defined structure would be better
16:29 <@idra> kblin, unless at kernel level the 128bit id is built off of a
96bit machine UUID + the regular 32bit uid :)
16:29 < kblin> that'd work, I guess