> > >>UID/GID solution
> > >>https://fedorahosted.org/sssd/ticket/1715
> > >>
> > >>Chaining access providers:
> > >>https://fedorahosted.org/sssd/ticket/1326
> > >I'm not sure these two are enough for a thesis..
> >
> > I think at least the first one is.
> > You change UID and/or GID on the server. And then you need a
> mechanism
> > to signal to the clients that they need to do cleanup. I was thinking
> > about OpenLMI integration in this case and this sounds like a research
> > topic to me.
> I see, this might be an interesting topic. I was initiall only thinking about 
> the
> change of the ID itself.

Something perhaps more worthy of thesis attention may be an examination of what 
it would take to start treating UID/GID as a completely internal machine 
representation which does not need to be shared. That is, it is important to 
have a common set of principal names for users, hosts and services in the 
Kerberos store; within an organization, it's important to have common groups of 
these principals in an LDAP store; but the importance of having all UIDs and 
GIDs be identical seems to be dwindling.

Authentication via Kerberos doesn't require it.
Authorization using Kerberos principals doesn't require it.
Moving files back and forth with SCP doesn't require it.
An NFSv4 fileserver w/krb5 security doesn't require it.
A CIFS fileserver doesn't require it.

What still requires that UID/GIDs need to be synchronized?

(I'm not necessarily asking you all right now. I think it might be a good 
thesis question, along with the follow-on: how much work would it take to 
migrate off of UID/GID synchronization for good?)


This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 

Freeipa-users mailing list

Reply via email to