Am 03.11.2015 um 16:44 schrieb buhorojo:> On 03/11/15 10:56, Ole Traupe wrote: >> >>>> 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? > Hi > The upcall will maintain the validity of the mount for as long as it > is accessed, so maybe a better question would be how long a ticket > does your kdc issue for a user. The latter will be the determining > factor, not the upcall.Up to 7 days if renewed within 24h, if I understand correctly (ticket_lifetime = 24h, renew_lifetime = 7d). Thanks for the clarification!> >> >> 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. >>> HTH >> >> Thanks. 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. > > We think that the only way with cifs on Centos is to get the source > and build it. If the rest of it is working but the upcalls are not > then keep with what you have, uninstall the cifs utils making sure the > binaries have been removed and are not at a non-standard location, > then make install.So there will be no conflict with other samba components such as in samba-common? And sorry for the typo, it is Samba 3.6.> > Good luck and HTHAgain, thank you very much!
On 03/11/15 17:18, Ole Traupe wrote:> > > Am 03.11.2015 um 16:44 schrieb buhorojo: >> On 03/11/15 10:56, Ole Traupe wrote: >>> >>>>> 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? >> Hi >> The upcall will maintain the validity of the mount for as long as it >> is accessed, so maybe a better question would be how long a ticket >> does your kdc issue for a user. The latter will be the determining >> factor, not the upcall. > > Up to 7 days if renewed within 24h, if I understand correctly > (ticket_lifetime = 24h, renew_lifetime = 7d). > > Thanks for the clarification!Sorry, we don't know what the renew_lifetime means. Ours last 8 hours, after which the mount is inaccessible.> > >> >>> >>> 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. >>>> HTH >>> >>> Thanks. 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. >> >> We think that the only way with cifs on Centos is to get the source >> and build it. If the rest of it is working but the upcalls are not >> then keep with what you have, uninstall the cifs utils making sure >> the binaries have been removed and are not at a non-standard >> location, then make install. > > So there will be no conflict with other samba components such as in > samba-common? > > And sorry for the typo, it is Samba 3.6. > > >> >> Good luck and HTH > > Again, thank you very much! > > >Hi No problem. Thank _you_ for the thread. We've an ongoing coursework on exactly this, except we have to automount it so most of the stuff we can test hands on. A lot of it we covered last year and we'd forgotten. Unfortunately although we have Fedora, opensuse and Ubuntu lab rigs, we don't do Centos.
Am 04.11.2015 um 09:31 schrieb buhorojo:> On 03/11/15 17:18, Ole Traupe wrote: >> >> >> Am 03.11.2015 um 16:44 schrieb buhorojo: >>> On 03/11/15 10:56, Ole Traupe wrote: >>>> >>>>>> 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? >>> Hi >>> The upcall will maintain the validity of the mount for as long as it >>> is accessed, so maybe a better question would be how long a ticket >>> does your kdc issue for a user. The latter will be the determining >>> factor, not the upcall. >> >> Up to 7 days if renewed within 24h, if I understand correctly >> (ticket_lifetime = 24h, renew_lifetime = 7d). >> >> Thanks for the clarification! > Sorry, we don't know what the renew_lifetime means. Ours last 8 hours, > after which the mount is inaccessible.As far as I understood what I have read: the ticket can be refreshed within 24h, up to a max lifetime of 7d (with these settings).