openid support for f9?

[Alan Cox]

On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote:
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.

They make certain assumptions about what a uid or gid is, and also about
the way they can be manipulated. However that is a *solved* problem.

> The UID/GID are *local* by nature. All tricks used up today like NIS and
> LDAP to sync UIDs/GIDs all over, are just *bad* hacks.

They work, they solve the problem for local users and they make it easy
locally to solve the "who owns this" problem, as opposed to the "can I ..." 
problem.

> 1. move to 128bit UID/GIDs that are really UUIDs
>   problem is, most apps wont work, need changes in the kernel, in a
> word:
> 	unachievable

This doesn't work anyway - a UUID is intended to avoid collisions, it is
not intended to be securely unique.

> 2. Make UIDs/GIDs *only* a local thing.
>   this mean changes in the vfs only, you need a mapping facility so that
> you can translate them for (network) file systems.

Yes - which unfsd supported in 1994 or so.

> I expect preconcept opposition for normal filesystems tho. But that is
> needed too, because if you want to use an USB pen drive or external
> disk, or even an iSCSI partition you need to be able to map a UUID
> stored on the filesystem to the local UID that make sense for the kernel
> and all existing applications, or you are back requiring all machines in
> the world synchronize with your own machines UIDs and GIDs.

For remote access to data you need to stop thinking in terms of "if I say
I am number 6 you say yes" and instead move to managing key chains via 
kerberos and similar systems - exactly as AFS has dealt with the problem
and NFSv4 has the framework to handle it.

Short of having a DNS like global "phonebook" for UIDs the solvable problem
is "can I have access to xyz"

Not co-incidentally the kernel has a key management service now, which is
ideal for such purposes.

Alan