On 10/25/2012 03:11 PM, KodaK wrote:
> On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal <d...@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.
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?

Would you be able to contribute some code for such feature?

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to