openid support for f9?

[Simo Sorce]

On Thu, 2007-11-08 at 13:09 -0500, Alan Cox wrote:
> 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.

Alan, I think we live on diffrent planets then :-)
I deal with ID mappings problems since ever in the Samba world, and I
rewrote the idmap subsystem twice, please trust me when I say the
problem is *far* from being solved, for anything but ideal cases which
do not exist on real networks.

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

They are a hack that can be made to work, but to me this is not a good
definition of "work", and they definitely do not "just work".

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

True, but there is almost no way to get something securely unique, and
anyway that's absolutely not the point. What we need is exactly to
avoiding collisions, not securely unique IDs.

> > 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 know, there have been experiments that's why I am somewhat confident
we can easily do this.

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

I think in CIFS terms, and there the problem was solved from scratch
basically. NFSv4 is ok too, as they finally moved from trusting the
client to not trusting it. But we have to do mapping for NFSv3.

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

Exactly, but yet you need to represent identity in term of UIDs and GIDs
in the POSIX world, hence why I am slowly advocating for *local* mapping
tables. Network mapping tables simply do not work.

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

Not sure what the key management thing wins you, if you mean to store
the mapping in there, yes it can be a huge help, but the mechanism we
use to store the temporary mappings is not important, what matter is
having filesystem (and not just netwrok ones) drivers support mapping,
with a way to store mappings on removable drivers when needed. Think
agaion of a USB pen drive formatted ext2, you need at least a file where
you map the UID used on the disk to the identity used (be it an email or
a kerberos principal or whatever you can think of to represent an
identity) and for groups too.