[Freeipa-users] Different primary group on different machines.

[Dmitri Pal]

On 10/25/2012 05:04 PM, KodaK wrote:
> On Thu, Oct 25, 2012 at 2:30 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 10/25/2012 03:11 PM, KodaK wrote:
>>> On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>>> On 10/25/2012 11:49 AM, KodaK wrote:
>>>>> I've been having users use the "newgrp" command to change their
>>>>> primary group on different machines.
>>>>>
>>>>> I've poked around in the docs a bit and I don't see this addressed.  I
>>>>> know, I know: "if it works, use it" -- but I'm wondering if I'm just
>>>>> missing a way to do it with IPA, or if there's another way to do it
>>>>> that might be better.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Jason
>>>>>
>>>> By reading the description of the command it seems that it works only
>>>> for local accounts.
>>>> So I suspect it is not effective in any case when the users come from
>>>> LDAP and not file.
>>>>
>>>> That brings the question: what is the use case and why you need it and
>>>> subsequently is there any other way to solve the problem you are trying
>>>> to solve with already existing means in SSSD?
>>>>
>>> I have users that need different primary groups on different machines.
>>>  The newgrp command works -- unfortunately putting it in a login
>>> script is a bad thing because newgrp reads those same login scripts,
>>> creating an infinite loop.
>>>
>>> We have many different development groups, but people can be members
>>> of multiple groups.  For collaboration, they'd like it when creating a
>>> file to have that file have a group ownership of "foo" on machine-A,
>>> but "bar" on machine-B.  I'd like to help the end users do this
>>> themselves so that I don't have to maintain separate files on each
>>> machine (one of the reasons I put in IPA in the first place. :) )
>>>
>>> Thanks,
>>>
>>> --Jason
>> I see it to be solvable in two different ways.
>> One centrally in IPA. Something like an extra attribute attached to HBAC
>> rule that would denote the alternative default group. This is just from
>> top of my head. I already see problems with this approach but anyways
>> this is one direction.
> I'd think it would have to be per-user or a separate policy area.
> "these users" get "this pgrp" on "these servers".
>
>> A different option is to have a local override in the sssd.conf and make
>> SSSD swap primary group for the user but then you would have to
>> configure it per user - not a nice approach too.
>> Hmmm may be some kind of the sss_chache related utility that would
>> update cache with the preferred GID, that would work as a command but
>> has other implications - dealing with fast cache and server side changes
>> that might override the value...
>>
>> Anyways not an easy fix. Can you please file an RFE?
> Sure.  Where do I do that?  :)  (I'm kidding, I'll google it.)
>
>> Would you be able to contribute some code for such feature?
> I'd love to say I could, but I'm not really a coder, and my day job
> has me working 50-60 hours a week as it is.  And when I say "I'd love
> to" I really mean it.  I'd rather be doing that than my day job. :)
>
> --Jason
Thank you for filing a ticket.
I suspect Google did its part... :-)
So you prefer it centrally managed.
Well... Right now it seems like a very corner case and with a workaround
as you mentioned so the best opportunity to make it implemented is to
actually find someone to contribute the code. 

I suspect it will be triaged as deferred at our next ticket triage
meeting which means that we will gladly accept patches but would not do
the work ourselves. The only other way to bump its priority is bring
into the conversation other deployments that are looking at the similar
functionality.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/