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