From Fedora Project Wiki

We can redesign the ACL system for cvs to make it easier to work with the current cvs acls.


  • letting probationary maintainers into cvs..with limited access to a small set of packages. The current sponsorship process can leave people and packages sitting in limbo for weeks
  • Let sponsors work on packages of those they've sponsored.
(09:30:52 AM) abadger1999: notting: Does breaking the cvsextras sandbox hurt us actually?
(09:31:11 AM) notting: abadger1999: if someone breaks the cvs restricted shell, yes
(09:32:37 AM) |DrJef|: notting, make the acl magic just work so i can have probational maintainers under my direct authority
(09:32:57 AM) notting: hm. having sponsors have access probably req. using pkgdb
(09:33:18 AM) notting: and locking the users out of other packages means *fs* ACL maintenance. which, ew.
(09:33:44 AM) ***notting mutters something about CVS sucking horribly
(09:33:51 AM) ajax: notting: uh?  cvs server can't determine account?
(09:33:58 AM) abadger1999: Can we manage the whole thing from the pkgdb in a sane way?
(09:34:10 AM) |DrJef|: notting, probational period is about the only process i can think of which will help us drop the length of time new people sit waiting for sponsorship
(09:34:15 AM) ajax: not that i care.  we're doing setfacl access on fd.o cvs, and it works fine.
(09:34:15 AM) notting: ajax: being able to commit requires a) write access to the files b) matching the ACL rules
(09:34:19 AM) ajax: fewer accounts though.
(09:34:24 AM) ajax: afk, lunch
(09:34:32 AM) notting: ajax: the biggest issue with setfacl is cleaning it up on owernship changes
(09:34:48 AM) |DrJef|: notting, im extremely keen on finding a way to make it easier for new people to get busy mangling bits
(09:35:15 AM) notting: since the logical (IMO) sandbox way would be to have newbies *not* be in cvsextras, but just have setfacl for their own packages onlyt
(09:35:56 AM) nirik: |DrJef|: I would also like to see us have alternative paths to sponsorship... like 'triage bugs' or 'write docs' or whatever... instead of 'review other packages'... we still need to see that they know the package guidelines tho.
(09:35:59 AM) |DrJef|: notting, basically put them in a different group and deal with acl's just for them?
(09:36:11 AM) |DrJef|: nirik, absolutely
(09:36:22 AM) notting: |DrJef|: right. but matching the 'current' ACLs doesn't help if they can't actually write to the files
(09:36:25 AM) abadger1999: notting: Would it be feasible to make all cvs acls be  fs acls and manage them with a script reading the info from the package db?
(09:36:30 AM) |DrJef|: nirik, which is why.. i would be on the hook for any packages pushed for people im mentoring
(09:36:55 AM) |DrJef|: nirik, but they would be doing cvs commits and building a track record.... so its should be obvious that they are worth sponsering after just a little bit of time
(09:37:20 AM) notting: abadger1999: if you want to do that in general, it would mean that package-with-ACL-for-only-one-user needs to actually be chowned/chgrped from package-open-to-all. which is kinda messy
(09:38:40 AM) abadger1999: notting: Why not set package-open-to-all as an acl as well?
(09:38:55 AM) |DrJef|: nirik, for triange.. i dont have any ideas... but once wwoods gets the testing harness hooked into bodhi writing test scripts may be a new path to sponsorship
(09:39:07 AM) notting: abadger1999: so, files are rw to nobody by default, and you do setfacl for cvsextras? doable, i suppose
(09:39:18 AM) notting: actually, i suppose they're rw to cvsadmin by default
(09:39:19 AM) abadger1999: notting: Yeah.
(09:40:11 AM) notting: it's doable. the one advantage to the current (tacked-on) ACL stuff is that it's a lot easier to browse
(09:40:26 AM) notting: as setfacl basically requires a shell account to investigate
(09:41:51 AM) abadger1999: If it's all managed through the packagedb we could have the packagedb dump a list of ACLs that is human parsable.
(09:42:02 AM) notting: right, but that's still secondary
(09:42:19 AM) abadger1999: Right.  for debugging what's actually on the system.  Hmm....
(09:43:16 AM) tibbs: The CVS acl script stuff is actually pretty simple.
(09:44:12 AM) tibbs: It just takes some files as arguments and the user from the environment and exits 0 if the user is allowed to modify those files.
(09:44:42 AM) tibbs: Any limitations that would require you to fall back to filesystem ACLs are purely limitations of the "acls" script.
(09:44:44 AM) notting: tibbs: right. but they still need write access to the underlying files
(09:45:06 AM) tibbs: notting: That's no different than what we have now, though.
(09:46:26 AM) notting: tibbs: true, but |DrJef| is talking about sandboxing new users. which requires either writing acls such that for 'open packages', the acl lists everyone in some manner, or restriciting the newbies with other means
(09:47:18 AM) tibbs: notting: My point is that you can restrict new users either by simply tweaking the "acls" script, or by replacing it with something that queries packagedb directly.
(09:47:59 AM) tibbs: The problems |DrJef| speaks of are limitations of the acls script which are not terribly difficult to get around.
(10:00:07 AM) |DrJef|: tibbs, notting: the technical specifics are just about 2 inches over my head at the moment... is a workable solution something achievable by f8?  there's a box of doughnuts in it for someone
(10:00:35 AM) notting: |DrJef|: let's get pkgdb going, and figure out from there
(10:00:43 AM) tibbs: |DrJef|: A simple implementation is just a few lines of Perl.
(10:01:11 AM) tibbs: |DrJef|: Add  a file containing users and the packages they are restricted to.
(10:01:30 AM) tibbs: The problem is that it requires maintenance, and packagedb is right around the corner, so...
(10:03:09 AM) |DrJef|: tibbs, you meant pythong right?
(10:03:15 AM) tibbs: No, perl.
(10:03:18 AM) |DrJef|: tibbs, oh im not it today....i just want to make sure this capability is on the roadmap
(10:03:28 AM) tibbs: The acls script predates the existence of the Python language as I understand it.