Am 02.11.2015 um 13:12 schrieb buhorojo:> On 02/11/15 12:54, Ole Traupe wrote: >> Hi all, this is not really a Samba question, but related, and I hope >> that some of you are using this and can tell me what I am doing wrong. >> >> On a member server, I can mount my shares by hand specifying "-o >> username=xxx,domain=yyy,password=zzz". But as soon as I put >> "sec=krb5" in the mount options (and leaving out the password part), >> I get this error: >> >> # mount error(126): Required key not available >> >> I did an extensive web search and saw that many people have problems >> here. But I found no definite solution. I tried to specify >> 'cruid=%(USERID)' in the case of pam_mount, or 'cruid=12345' in the >> manual case (12345 being the literal uid of the user). I also tried >> getting rid of the strange file ending of the krb5 key cache, because >> in my case it is e.g. "krb5cc_12345_Zb1yLU". And I tried chowning the >> file to root:root instead of user:domain users. Nothing worked. >> >> The krb5 key cache files are created in /tmp on user logon. Is this >> the correct lookup directory, in the first place? >> >> Kerberos as such is working correctly. Domain logons work, kinit as >> well. This is on CentOS 6.7. Pam_mount was installed via the Nux >> Desktop repo. >> >> Best, >> Ole >> >> >> > Hi > You need multiuser. > > Either use a key you already have: > mount -t cifs //yourserver/share /share -osec=krb5, > username=MACHINE$,multiuser > > Or create an unprivileged domain user to mount the shares and add that > key to the keytab. Use the mutiuser switch to mount the share on > behalf of anyone who needs it: > mount -t cifs //yourserver/share /share -osec=krb5, > username=user4cifs,multiuser > > We recommend the second method as the first way is easy to hack. > HTHThank you, I will try this! However, I am not sure I understand why it is necessary and whether it works as intended. Why can't the user do it with his own key file? Also, if the user is not mounting his home share, but somebody else, this _other_ user will be the owner of newly created files and folders, right?
On 02/11/15 14:42, Ole Traupe wrote:> > Am 02.11.2015 um 13:12 schrieb buhorojo: >> On 02/11/15 12:54, Ole Traupe wrote:>> Why can't the user do it with his own key file?Only root can perform mounts and anyway, cifs upcall looks for a key, not a cache.> > Also, if the user is not mounting his home share, but somebody else, > this _other_ user will be the owner of newly created files and > folders, rightNo. With multiuser, acl and permissions are respected. If the user would normally be the owner of newly created files, then he will be also over cifs. One other thing, you need a recent version of cifs utils (we don't think Centos has) and to make sure that you lose the -c at /etc/request-key.conf: create cifs.spnego * * /usr/sbin/cifs.upcall -c %k HTH
Am 02.11.2015 um 15:10 schrieb buhorojo:> On 02/11/15 14:42, Ole Traupe wrote: >> >> Am 02.11.2015 um 13:12 schrieb buhorojo: >>> On 02/11/15 12:54, Ole Traupe wrote: > >>> Why can't the user do it with his own key file? > Only root can perform mounts and anyway,Right, sorry.> cifs upcall looks for a key, not a cache.So you just _have_ to use the keytab. Has this changed? Here it seems that cache was ok in the past (see the end of the longest cited log part in the middle; but there was a different problem, obviously, with ownership): http://www.spinics.net/lists/linux-cifs/msg05290.html>/Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: considering/tmp/krb5cc_101125/>/Jan 25 17:55:12 goto cifs.upcall: find_krb5_cc: /tmp/krb5cc_101125 isowned by 101125, not 0/ I mean, putting the key in the keytab looks like a security risk to me. Would be nice if you could use kerberos on the fly. Unfortunately, I don't find such a detailed log in /var/log/messages.>> >> Also, if the user is not mounting his home share, but somebody else, >> this _other_ user will be the owner of newly created files and >> folders, right > No. With multiuser, acl and permissions are respected. If the user > would normally be the owner of newly created files, then he will be > also over cifs.Great, that sounds exactly as I would like it to be.> > One other thing, you need a recent version of cifs utils (we don't > think Centos has)Mine is cifs-utils.x86_64 4.8.1-20.el6> and to make sure that you lose the -c at /etc/request-key.conf: > create cifs.spnego * * /usr/sbin/cifs.upcall -c %k > > HTH > >
Am 02.11.2015 um 15:10 schrieb buhorojo:> On 02/11/15 14:42, Ole Traupe wrote: >> >> Am 02.11.2015 um 13:12 schrieb buhorojo: >>> On 02/11/15 12:54, Ole Traupe wrote: > >>> Why can't the user do it with his own key file? > Only root can perform mounts and anyway, cifs upcall looks for a key, > not a cache. >> >> Also, if the user is not mounting his home share, but somebody else, >> this _other_ user will be the owner of newly created files and >> folders, right > No. With multiuser, acl and permissions are respected. If the user > would normally be the owner of newly created files, then he will be > also over cifs. > > One other thing, you need a recent version of cifs utils (we don't > think Centos has)Can this be snatched from Fedora?> and to make sure that you lose the -c at /etc/request-key.conf: > create cifs.spnego * * /usr/sbin/cifs.upcall -c %kOk, I don't have this line at all. Will copy&paste it (without -c).> > HTH > >