[Samba] Pam_mount not working with "sec=krb5"

[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.
>
>
>>
>>>
>>> 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.