ALT Linux Bugzilla – #19199

Пункты 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