samba - May 2015 - [Solved] A working CUPS authentication now fails without change anything...

On Tue, 12 May 2015, Andrey Repin wrote:
> Greetings, Daniel Carrasco Mar?n!
>
>> Hi again!!, this time is not for help request as always :P finally
i've
>> found the solution and I want to share it.
>> The problem was just permissions. If you change the keytab permission
to
>> 644 it works perfect: chmod 644 /etc/krb5.keytab
>> Anyway I don't understand why the daemons can't read that file
when are
>> running as root.
>
> Not all daemons are run as root, far from that.
> Most of single-purpose daemons, such as cups, run as their own users.
Yep, this is done for security purposes so that if one process is 
compromised, it doesn't have administrative access to the rest of the 
system.

In a similar vein, you don't generally want any process on the machine to 
have access to some things.  The system kerberos keytab is probably one of 
those.  If cups is running as it's own user, a better solution would be to 
either generate a new keytab just for cups, or copy the existing keytab 
and make it only readable by the cups user.

2015-05-12 19:45 GMT+02:00 Sketch <smblist at rednsx.org>:
> On Tue, 12 May 2015, Andrey Repin wrote:
>
>  Greetings, Daniel Carrasco Mar?n!
>>
>>  Hi again!!, this time is not for help request as always :P finally
i've
>>> found the solution and I want to share it.
>>> The problem was just permissions. If you change the keytab
permission to
>>> 644 it works perfect: chmod 644 /etc/krb5.keytab
>>> Anyway I don't understand why the daemons can't read that
file when are
>>> running as root.
>>>
>>
>> Not all daemons are run as root, far from that.
>> Most of single-purpose daemons, such as cups, run as their own users.
>>
>
> Yep, this is done for security purposes so that if one process is
> compromised, it doesn't have administrative access to the rest of the
> system.
>
> In a similar vein, you don't generally want any process on the machine
to
> have access to some things.  The system kerberos keytab is probably one of
> those.  If cups is running as it's own user, a better solution would be
to
> either generate a new keytab just for cups, or copy the existing keytab and
> make it only readable by the cups user.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
Yes, for now keytab is compromised.

Cups calls pam authentication, and pam use winbind then I need to give
permissions to winbind daemon but i don't know what account is using that
daemon. How i can see it?, because ps aux shows the most as root.

Greetings!!

Greetings, Daniel Carrasco Mar?n!
>>>  Hi again!!, this time is not for help request as always :P finally
i've
>>>> found the solution and I want to share it.
>>>> The problem was just permissions. If you change the keytab
permission to
>>>> 644 it works perfect: chmod 644 /etc/krb5.keytab
>>>> Anyway I don't understand why the daemons can't read
that file when are
>>>> running as root.
>>>>
>>>
>>> Not all daemons are run as root, far from that.
>>> Most of single-purpose daemons, such as cups, run as their own
users.
>>>
>>
>> Yep, this is done for security purposes so that if one process is
>> compromised, it doesn't have administrative access to the rest of
the
>> system.
>>
>> In a similar vein, you don't generally want any process on the
machine to
>> have access to some things.  The system kerberos keytab is probably one
of
>> those.  If cups is running as it's own user, a better solution
would be to
>> either generate a new keytab just for cups, or copy the existing keytab
and
>> make it only readable by the cups user.
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
> Yes, for now keytab is compromised.
> Cups calls pam authentication, and pam use winbind then I need to give
> permissions to winbind daemon but i don't know what account is using
that
> daemon. How i can see it?, because ps aux shows the most as root.
winbind normally have access to Kerberos keytab by default.
I see no reason why it would not.


-- 
With best regards,
Andrey Repin
Tuesday, May 12, 2015 22:28:05

Sorry for my terrible english...