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 > >
>> >> 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 >Ok, I at least need 5.3. https://wiki.samba.org/index.php/LinuxCIFS_utils
Am 02.11.2015 um 16:06 schrieb Ole Traupe:> >>> >>> 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 >> > > Ok, I at least need 5.3. > > https://wiki.samba.org/index.php/LinuxCIFS_utils >I have found this src.rpm: ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/network%3A/samba%3A/TESTING/CentOS_6/src/cifs-utils-5.9-94.3.src.rpm If it works, will it conflict with Samba 3.1 on CentOS 6? I know that Samba 4 and cifs-utils 4.8 are incompatible: https://bugzilla.redhat.com/show_bug.cgi?id=984727 But this is the other way around (cifs-utils 5.9).
On 02/11/15 15:51, Ole Traupe wrote:> > > 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 is > owned by 101125, not 0/ > > I mean, putting the key in the keytab looks like a security risk to me.In what way does it appear any more of a risk than having the keys which you have there already? Even if someone steals the keytab, they're gonna be hard pressed to crack the key in the few hours before the tgt expires. Do you have very sensitive data maybe?> Would be nice if you could use kerberos on the fly.You _are_ using it on the fly.The tgt is obtained without any interaction on the part of the user.> > 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.el6We can confirm it works with 6.2. HTH> >> and to make sure that you lose the -c at /etc/request-key.conf: >> create cifs.spnego * * /usr/sbin/cifs.upcall -c %k >> >> HTH >> >> >
>> I mean, putting the key in the keytab looks like a security risk to me. > In what way does it appear any more of a risk than having the keys > which you have there already? Even if someone steals the keytab, > they're gonna be hard pressed to crack the key in the few hours before > the tgt expires. Do you have very sensitive data maybe?Ok. And maybe I misunderstood something: I thought the key would be valid indefinitely, while the ticket expires. But then there is the Ticket-Granting-Ticket (TGT). And if also the TGT expires after a few hours, for how long will a share mounted with "sec=krb5,multiuser" be accessible to the user? I am sorry for all these dummy questions, but I really find this matter hard to understand. Thank you very much for your help!>> Would be nice if you could use kerberos on the fly. > > You _are_ using it on the fly.The tgt is obtained without any > interaction on the part of the user. >> >> 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 > We can confirm it works with 6.2. > HTHThanks. So migrating the server to CentOS 7 would be advised here if one is afraid of bad interactions of Samba 3.1 with later (and potentially buggy) experimental cifs-utils versions for CentOS 6.