58246 - add ssh-account support to despot

Status: RESOLVED INCOMPLETE

(Webtools Graveyard :: Despot, defect, P1)

Description

[mike.clarke]

This is one of the requirements of the upcoming XUL version.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Mass re-assign of despot bugs to [e-mail], the new owner.  I'm
switching groups to go work on mozilla LDAP integration.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

2nd try: mass re-assign of webtools bugs to endico, as I'm switching groups to
work fulltime on LDAP integration in Mozilla.

Comment 3

[Dave Miller [:justdave]]

I'm going to call the lack of this feature a bug so I can get it high on the
severity list.

This is very important for our security.

Reassigning to nobody since nobody's actually working on it yet (that I know
of).  We need to find someone to do this soon.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

So here's a proposal for how to fix this:

 * webtools/despot/despot.cgi needs to be modified to have UI for ssh keys and
store them in the database

 * webtools/despot/syncit.pl needs to generate CVSROOT/ssh-keys just like it
generates CVSROOT/passwd.  It needs to have on each line, a username, whether
they're a cvsadm or not, and their ssh key.

 * we need to write a post-commit script (sync-ssh-keys.pl) and check it in to
CVSROOT/ (can be done by any cvsadm).  I'm willing to write and test this part.
 It would do the following:
 + for each directory in /cvsdisk/jail/users/ (with one or two hardcoded
exceptions), check that the name of the directory is in CVSROOT/ssh-keys, and if
not, and there's a username corresponding to the directory name whose home
directory is that directory in /cvsdisk/jail/users/, remove the user (and remove
his home directory)
 + for each user in CVSROOT/ssh-keys, if he's not listed in /cvsdisk/jail/users/
and there's no current account with that user's account name, do what the script
we've currently been using to add ssh keys does
 + add or remove the cvsadm group for each user based on similar data

 * we need to add ssh-keys and sync-ssh-keys.pl to CVSROOT/checkoutlist (can be
done via cvs by any cvsadm)

 * we need to modify CVSROOT/loginfo so that any changes to CVSROOT/ssh-keys
cause sync-ssh-keys.pl to be run (likewise, can be done by any cvsadm, but a
tiny bit tricky when there's already something that needs to be done for CVSROOT/*)

Does this seem like a reasonable approach?

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #4)
> whether they're a cvsadm or not

Or this could store it in the more general form: primary group (always cvsuser
for cvs and webcvs for gila) and additional groups (a list, but currently the
only option is cvsadm).

Comment 6

[Dave Miller [:justdave]]

(In reply to comment #4)

> Does this seem like a reasonable approach?

Sounds reasonable to me.  Although I'm a bit nervous about having the script
that creates the actual accounts live in CVS (only for reason of someone who
manages to get cvs admin access illicitly being able to commit a revised version
that creates a real shell account instead of an anoncvssh one, or do any number
of other Bad Things since the script will need to run as root outside of the
chroot).

Comment 7

[Colin Ogilvie [:cso]]

Attachment: Despot Patch

Implements the despot side of dbaron's suggestion...

Tested the DB storing, and it works. The file creation works, but I can't test checkin etc. as I can't get that working for some reason.

Comment 8

[Dave Miller [:justdave]]

ok, this is a really novel suggestion, but...

How about having a cron job on the CVS server which directly connects to the MySQL database and does the key comparison described rather than having them in CVS?

When despot commits, it has the same access rights as any other CVS committer - that being they're chrooted inside /cvsdisk/jail when the commit happens.  This means any script which is executed as a post-commit script won't work, because it needs to run outside of the jail in order to create accounts.

So having a cron job just sync the keys and groups out of the despot database would probably be the next-best thing.

Comment 9

[Dave Miller [:justdave]]

OK, so we have a couple machines now with openSSH successfully authenticating against ssh keys retrieved via LDAP.  The way to go with this is to just throw the ssh key into the user's entry on the LDAP server and get the LDAP key retrieval enabled on the cvs server.

Much of the data despot stores probably has a lot of overlap with the type of stuff that's being stored on the LDAP server, so maybe we can convert despot to being backed by LDAP instead of MySQL while we're at it (but that's probably a different bug)

Comment 10

[Takanori MATSUURA]

This bug lies at rest in the graveyard.