Created attachment 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
Пункты 1-4 нужны для ветки 5.0
Created attachment 3374 [details] ip-to-hostname Патч взят отсюда: http://patchwork.kernel.org/patch/4594/ Не уверен что он нам нужен. У меня и без него работает.
Пункт 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 о котором говорилось выше.
Еще один интересный факт (отношения к 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
К пунку 4. https://bugzilla.samba.org/show_bug.cgi?id=6194 К Пункту 1. https://bugs.launchpad.net/ubuntu/+source/samba/+bug/236830
В 3.0.33-alt2 сделал поддержку cifs.upcall, немного не так, как в предлагаемом патче от Debian, потому что в Debian сделали больше вмешательств, чем требовалось. Пункт 2 исправлять не буду. Пункт 2 представляет собой неверное решение общей проблемы -- используйте winbindd/pam_winbind, как это рекомендовано в документации уже несколько лет. pam_smbpass более не поддерживается. Пункт 4 исправлять в рамках 3.0 не имеет смысла. Вернемся к нему в 3.3-3.4.
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