-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff and I ended up digging pretty deep into our auth subsystem and came up with a bunch of issues. I'm thinking next sprint we should take some time to revamp our auth handling to clean this up.
- - The two CLIs improperly use each other's certificates. Currently, both utilize the same preference scheme for determining the type of auth to use (username/pass, admin cert, consumer cert). This leads to some wonky situations where a machine with both a consumer and admin cert will use the admin cert for consumer operations, which leads to (among other things) incorrect reporting of who initiated the action. The desired behavior should be based on which CLI is being invoked: * pulp-admin: if a username/password are specified to the executable, use those; otherwise, use an admin certificate if one exists. * pulp-client: all commands require a consumer certificate except for consumer create; username/password should be moved from being an executable-level option to specific only to consumer create. In other words, you use a username/password to get the consumer cert, but then the consumer cert is the only way to do consumer operations from pulp-client from there on. - - The role checking lines between admin (read: user) and consumer are blurred. Currently, we try to log you in as an admin. If we cannot, we try to log you in as a consumer. I know we're reusing the same APIs for both admin and consumer operations (in other words, if a consumer is binding itself or an admin is binding a consumer, we use the same call), but this just feels wrong. It allows the bug we face today, that admin credentials are used for consumer initiated operations. The two concepts, users v. consumers, are apples and oranges, but we don't reflect that properly. I haven't looked yet, but I doubt our API docs properly reflect this as well. The consumer ID is required in all cases of the API, but I don't think we document the auth requirements to make the call (those requirements read something like "You either need to have the consumer cert of the consumer with the same ID as the call edits OR you need to have admin credentials"... and this is all before we have anything role-related in place, which further complicates this). - - Any consumer can edit another consumer. Our consumer verification ensures that the consumer ID in your certificate is a valid consumer, but doesn't actually check to make sure it's the consumer the API call is acting on. Big security hole here. - - The principal handling (auth.py) has a few issues: - -- It is only set for admin users; the principal is left at the default when a consumer initiated (pulp-client) command is run. - -- The SystemPrincipal implementation is wonky. It's not a subclass of User, yet is meant to be treated as one. What this leads to is checking elsewhere in the code where you get the principal but then have to determine if it's an actual user before being able to access data on it. - -- The principal is not reset on each call to role check, which means if a thread with a principal is set and tossed back into the pool, the next call that uses that thread again is by default logged in. - - All certificates, both admin and consumer, are generated with the same serial number. This prevents us from ever implementing a certificate revocation list (I just filed a bug on this this morning). - -- Jason Dobies RHCE# 805008743336126 Freenode: jdob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM4XVzAAoJEOMmcTqOSQHC2NUH/RvICKahbCJ5fatdX0nbqKFf 2l2XD2qlqJTofEumGE9yNQ7O1SzwndKbRcWjXc8JJlfmPLElmyjlQuU/zCiWuSSr sIOhpqD73mgzm8iT4oMmWUUmHKI0uOQ6SwaoZZbYA5M/UnJZoPfEkrwOVbOKeW/C XrMRYccFisF5PG7hCbK/W4WYobvpgo4u2Q68BTJMPBNsgiFPf89E5/+A6SpEgpy1 4CebQ4D6NTEtG3b64quVdZ5UZ4lvSUAdLmBZajtMmgRj2QtMYn2qFzkMvezI3Y+T 7ssFuzc/Y9og6tHRkfC0Y/IeNgX4lkAaMDQj2oMtCkOpoaQ/fvydC120q8BJQdg= =Ke5n -----END PGP SIGNATURE----- _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
