On Sat, 2014-03-08 at 01:19 +0000, Nordgren, Bryce L -FS wrote: > I'm not suggesting that POSIX machines stop using UIDs internally. The > local persistent map to a machine dependent representation will be > necessary. It will also be necessary on Windows machines. And on > mobile platforms. And within web applications. The shared items > (principal names) would be common to all OSes and platforms though.
True, however posix information carry also other data, notably home directory, gecos and shell. If you never share home directories you can synthesize a home dire locally. And you could claim that everyone uses bash and has to change the shell on each machine independently. Gecos could also be ignored, although it is used in most desktops to show a 'nice' name when your login is something like kxy3456yt ... So yes you can probably forfeit all the user related information, however it is rarely ok to forfeit groups, so you still need to synchronize those around at least in homogeneous islands of activity. > People trying to create heterogeneous environments are already > carefully restricting protocols and applications to those which don't > require sharing a UID map. File sharing via: Samba/CIFS, NFSv4, > WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple > machines has never involved knowing your UID, and ssh key pairs makes > it more or less effortless to execute commands on another machine > whether or not your username is the same, much less your UID. Kerberos > SSO is more or less the same, but ensures that a common set of > identities are recognized. True, but the ability to successfully login does not exhaust the reason why you have a common directory, there is other data that is synchronized and shared. > Ideally, if realm admins delegate authorization to the individual > machines, the machines (regardless of OS) should be capable of > functioning with only Kerberos authentication and without any > centralized directory services. Only if you think grouping mechanism are not necessary, I do not think that's the case in any current deployment. > Minimal directory services could add group definitions via LDAP. I guess you need to define what 'minimal' would mean here :) > A full AD/IPA solution would be needed to centralize authorization > and/or enforce policy. Yet I still am not seeing the requirement for > new deployments of cross-platform environments to manage internal user > representations for a single os. I am not sure I understand what you mean by 'single os' here, they manage IDs as a single domain. Now, Posix is unfortunately limited by the fact that it has a single user space and a single group space because it was standardized when networks where rare and there were no concepts of groups of machines with homogeneous identity stores. It would be nice to fix this problem, but it is not simple to do it right, and it would require kernel support to do it right. > > 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). > > Presumably, you also would not want your Windows users to lose access > to files after a rename, and Windows doesn't use UIDs. Windows uses SIDs, they are perfectly equivalent to UIDs in this discussion, although they have better properties when it comes to networked machines. In fact, over CIFS, SIDs are used to set ACLs, and in general you cannot properly operate a Windows-centric domain if you do not have SID<->Name translation services provided by the Domain Controller. > You also would not want to lose access to web apps, which do not use > UIDs. Web apps often duplicate the whole user database and have their own groups, yet in enterprises they are also commonly integrated with a directory for authentication and groups. They can ignore UIDs, just like any other application, indeed. > You also don't want stale usernames to be sitting in access control > lists (filesystem based or web app based). Indeed which is why all filesystems tend to use UIDs (or SIDs for NTFS) to perform access control. Unfortunately web applications almost always do use usernames for access control, which is why renames are harder there. > Retaining UIDs does nothing to make renaming more acceptable, because > principal names are a realm-wide platform independent property, and > UIDs are not. This is debatable, but I do grant renames always need to be treated carefully, however homogeneous UIDs/SIDs allow renames to happen. Without UIDs stored in filesystems renames would simply not be possible, w/o administrators running on every single machine and operating local changes. > > 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 ... > > As I see it, for a cross-platform environment, every problem must be > worked around regardless of whether you have to synchronize UIDs. > Managing UIDs is just more work at the end, and it might be busywork. > Determining whether it's busywork or not may make a good thesis > topic. :) Well, we try to make it so you, administrator, do not have to deal with it if not rarely in freeIPA. So it shouldn't be busywork for sure. Would like to know if anyone has a different experience and found themselves in need to tinker for long with UIDs in an IPA environment. > It makes a good thesis topic because the central question is paradigm > shifting: Draw a line between realm-wide properties and local machine > representations of those properties, and ask "Can each machine be made > responsible for performing their own localizations for internal > bookkeeping purposes?" This would seem to be of particular interest to > the type of crowd which would download and use a FreeIPA/sssd > solution, but it may not be something they have the time to pursue. In abstract I think there isn't much to research, this kind of operation has been experimented for a while for real. Local mappings have been done for as long as Samba/Winbindd have existed, as in the old days there was no "central" LDAP servers, and NT4 Domains were not extensible, so you had to create local ids for users. However the fact each machine had a different view of the UIDs caused issues when said machine needed to share files. Granted, "some" of this would be easier today, but not hugely so. This is why idmapping in the samba project has been a long and thorny issue with multiple backends being invented and the most successful ones being the ones that can predictably map Windows SIDs so that all Linux machines get the same UIDs for the same users after mapping. Going forward it is possible that local network file systems will become less and less relevant, and groups will become more and more localized into applications instead of being enterprise-wide, with enterprises asserting properties of users instead of their groupings and deferring to applications to deal with what to do with these attributes. Eventually we may get to a point where multiple machines do not need to share and synchronize much user data in the traditional way. But that time has not arrived yet, IMHO. (Which is not to say I wouldn't want to get there, it would be nice to get rid of this nasty problem :-) Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users