On Fri, 2014-03-07 at 20:38 +0000, Nordgren, Bryce L -FS wrote:
> > > >>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?)
a very thought provoking question, and it would be very nice if we
could, indeed, get rid of Posix IDs, however we can't.
One of the reasons is the dreaded 'legacy' applications and protocols.
You *could* build a system that can work w/o synchronization, if you
carefully restrict what protocols and applications you use (think about
distributed filesystems) although you'd still need a local persistent
map at least. Backups and restore to other machines would need to be
done carefully though, and so on.
However there are also issues with operations like 'renames', what
happen when you change a user name or a group name ? You do not want to
lose access to files when that happen, so you still need a unique
identifier that is not the everyday name (or forbid renames).
This is not an exhaustive list of course, and every problem can be
probably worked around one way or another, however at the moment it is
till "easier" to synchronize IDs than not ...
Simo Sorce * Red Hat, Inc * New York
Freeipa-users mailing list