Please, reinstate my access to overlays.gentoo.org. The only thing I need to do there is: makepasswd -ch 10; /usr/sbin/htpasswd2 svn/proj/sunrise/conf/svnusers <username> to add users to sunrise overlay. thanks.
jokey: I'd like some input and a list of what the following folks were doing in the authorized_keys for goverlays on egret: pva tommy rbu dberkholz genstef If they are doing extremely limited stuff like adding a user to sunrise, they shouldn't have access to the rest of the goverlays stuff - and more so, nobody should be using that .authorized_keys file, since we cannot then audit who actually logged in (ssh doesn't log which of the multiple keys was used).
i used my access to maintain sunrise (adding users, possible removal of users, which was not needed until now, changing svn permissions for the directorys/files in the overlay). I also added pva to .authorized_keys, so he could add users to sunrise overlay. I did not know that this was not allowed nor this needed interaction with infra.
tommy: which files were you talking about, give me a full path. "changing svn permissions for the directorys/files in the overlay" rbu/dberkholz/genstef: I'd like to know exactly what you did with your shell access to the goverlays user as well.
(In reply to comment #3) > rbu/dberkholz/genstef: > I'd like to know exactly what you did with your shell access to the goverlays > user as well. I have been investigating the reason for the front site (planet script on overlays.g.o) screwing up when a commit is made that contains ||, but that was merely reading files. Furthermore, I maintained access lists (htpasswd, htgroup) for security and my overlay.
ok, so far I've got it worked down to the following. Repos with something custom: proj/gentopia (users, no svnperms, standard groups) proj/java (svnperms, no custom users, standard groups) proj/php (svnperms, no custom users, standard groups) proj/sunrise (svnperm, custom users, no custom groups) If not listed, the repo has standard users (toplevel htpasswd), standard groups (toplevel htgroup) and no svnperms. rbu: I don't see any config files other than the top-level htpasswd/htgroup, were you just editing those for proj/security and dev/rbu? Could you describe the || problem better, or is it totally gone? tommy, pva: Do you need anything outside of this list of commands? # sudo -u goverlays htpasswd2 ${SVNROOT}/proj/sunrise/conf/svnusers # sudo -u goverlays rvim ${SVNROOT}/proj/sunrise/conf/svnperms.conf The rvim one i'd prefer not to include at all (it's mildly exploitable). beandog: Do you know of any issues when using planet and having a "||" literal?
I was fixing git overlays because they broke constantly. This seems to be mostly resolved at this point.
dberkholz: ok, that was only because the really old overlays were using Git-HTTP, instead of the real Git protocols, so I'll strike you from the list of needing direct SSH access to run stuff. Thanks for the response.
(In reply to comment #5) > Do you need anything outside of this list of commands? > # sudo -u goverlays htpasswd2 ${SVNROOT}/proj/sunrise/conf/svnusers > # sudo -u goverlays rvim ${SVNROOT}/proj/sunrise/conf/svnperms.conf > The rvim one i'd prefer not to include at all (it's mildly exploitable). Personally I don't need anything besides adding user's access to sunrise. If somebody of users will need higher level of access I can ask tommy or fill a new bug. Thank you for your work, btw.
(In reply to comment #5) > I don't see any config files other than the top-level htpasswd/htgroup, were > you just editing those for proj/security and dev/rbu? Yes, just those. > Could you describe the || > problem better, or is it totally gone? It is not gone, and it is caused by trac. Trac uses its wiki engine to format commit messages (trac option wiki_format_messages), so we get inter-trac links (like bug links, or 'r30' as a link). However ,that option parses the complete wiki syntax, including translating || to <td> tags. This HTML code is also exported via RSS, and since the overlays.g.o is only a planet aggregator, when the blog posts mess with <td>, the site gets screwed up.
Ok, so how do you quote "||" in the pipeline between the commit message and the Trac pickup so that it doesn't interpret the characters?
(In reply to comment #10) > Ok, so how do you quote "||" in the pipeline between the commit message and the > Trac pickup so that it doesn't interpret the characters? I have searched for that option briefly, but without success. It might be able to html-encode the pipe symbol, but that would look ugly in the svn history. The upstream bug to enable only partial wiki quoting is: http://trac.edgewall.org/ticket/4778
> ok, so far I've got it worked down to the following. > > Repos with something custom: > proj/gentopia (users, no svnperms, standard groups) > proj/java (svnperms, no custom users, standard groups) > proj/php (svnperms, no custom users, standard groups) > proj/sunrise (svnperm, custom users, no custom groups) What does custom groups mean? Sunrise has 2 groups: users (mainly no write access to sunrise/reviewed) and devs (with write access to sunrise/reviewed). > tommy, pva: > Do you need anything outside of this list of commands? > # sudo -u goverlays htpasswd2 ${SVNROOT}/proj/sunrise/conf/svnusers > # sudo -u goverlays rvim ${SVNROOT}/proj/sunrise/conf/svnperms.conf > The rvim one i'd prefer not to include at all (it's mildly exploitable). I need addings users and the right to edit svnusers and svnperms.conf, so both + # sudo -u goverlays rvim ${SVNROOT}/proj/sunrise/conf/svnusers
(In reply to comment #12) > What does custom groups mean? Sunrise has 2 groups: users (mainly no write > access to sunrise/reviewed) and devs (with write access to sunrise/reviewed). "standard groups" AuthGroupFile /var/www/overlays.gentoo.org/htgroup "standard users": AuthUserFile /var/www/overlays.gentoo.org/htpasswd "custom users": AuthUserFile /var/www/overlays.gentoo.org/svn/proj/sunrise/conf/svnusers Sunrise has NO "AuthGroupFile" configured at all. Updated list of repos with something customized: proj/java - pre-commit:svnperms - standard users - standard groups - pre-revprop-commit:none - post-commit:CIA-gentoo proj/php - pre-commit:svnperms - standard users - standard groups - pre-revprop-commit:none - post-commit:CIA-gentoo proj/sunrise - pre-commit:svnperm - custom users - no groups - pre-revprop-change:jokey-only - post-commit:CIA-sunrise (I removed gentopia, they have a file of custom user passwords, but it's not actually used). For all other repos not listed: - pre-commit:none - standard users - standard groups - pre-revprop-commit:none - post-commit:CIA-gentoo > I need addings users and the right to edit svnusers and svnperms.conf, so both How often do you change svnperms.conf? If it's really often, I'll come up with some solution to edit it without being privileged. (And maybe also put it under version control at the same time).
genstef, jokey: I still haven't had any input from you. Please review this bug.
(In reply to comment #13) > How often do you change svnperms.conf? If it's really often, I'll come up with > some solution to edit it without being privileged. (And maybe also put it under > version control at the same time). svnperms.conf is rarely changed. The sunrise-dev-group is defined in there, so adding/removing sunrise-devs. Also infrequently changes like forbidding commits to use.local.desc.
(In reply to comment #1) > jokey: > I'd like some input and a list of what the following folks were doing in the > authorized_keys for goverlays on egret: > pva > tommy > rbu > dberkholz > genstef > > If they are doing extremely limited stuff like adding a user to sunrise, they > shouldn't have access to the rest of the goverlays stuff - and more so, nobody > should be using that .authorized_keys file, since we cannot then audit who > actually logged in (ssh doesn't log which of the multiple keys was used). > You're right here. Actually I didn't even know people directly used that. Genstef took care of getting access for the people and up to now I thought these have been set up like I was (getting a custom user to do sudo goverlays and then work)... other than that it seems like I was mostly the only one setting up overlays for people given the mailflow that happened on overlays@ alias. other people commented here what they do so it's documented.
Ok, this should be resolved for everybody now. Here is how to use it on the new stuff. 1. Login as yourself with your SSH key! (assuming I didn't muck it up, I think I might of). 2. Use one of the following: tommy, pva: # sudoedit -u goverlays /var/svnroot/proj/sunrise/conf/svnperms.conf # sudoedit -u goverlays /var/svnroot/proj/sunrise/conf/svnusers rbu: # sudoedit -u goverlays /var/www/overlays.gentoo.org/htgroup # sudoedit -u goverlays /var/www/overlays.gentoo.org/htpasswd jokey: Anything listed above, "su - goverlays", able to stop/start/restart/reload apache2 init.d, plus the ability to chown in the following directories: /var/www/overlays.gentoo.org/conf/ /var/www/overlays.gentoo.org/htdocs/ /var/www/overlays.gentoo.org/trac/ /var/www/overlays.gentoo.org/planet/ /var/svnroot/ genstef: you didn't respond. No access for you. dberkholz: I removed your access since you didn't need it anymore.
ssh overlays.gentoo.org => Permission denied (publickey). I am also missing the mainly used command for me, pva (and jokey): # sudo -u goverlays htpasswd2 ${SVNROOT}/proj/sunrise/conf/svnusers And pva does not need the other two commands (edit svnusers or svnperms.conf).
Try the login again, I should have fixed the SSH keys now. You will find your passwords for the system at "~/.../.pass" - please reset them. Ok, so new changes to sudo commands allowed (when cfengine kicks the file out in 30 minutes). 1. "sudoedit /var/svnroot/proj/sunrise/conf/svnperms.conf" is limited to tommy+jokey (plus infra obviously). 2. The following htpasswd2 variants are allowed: FILE: /var/svnroot/proj/sunrise/conf/svnusers OR /var/www/overlays.gentoo.org/htpasswd FLAGS: -m OR -s OR -d OR -D sudo -u goverlays /usr/sbin/htpasswd2 $FLAG $FILE jokey, pva, tommy: the svnusers for sunrise. jokey, rbu: the htpasswd file for all overlays. The sudoedit is there as before, to enable users to send you pre-existing password hashes that you can insert. It will open up your $EDITOR in a safe fashion, and allow you to edit the contents before saving back to the original location. It's nothing you couldn't do htpasswd2, just easier in some ways.
Login works fine, sudoedit does not. rbu@pelican ~ $ sudoedit -u goverlays /var/www/overlays.gentoo.org/htgroup sudoedit: /etc/sudoers is mode 0600, should be 0440 Thanks for the setup (once it works :-)!
(In reply to comment #19) > Try the login again, I should have fixed the SSH keys now. You will find your > passwords for the system at "~/.../.pass" - please reset them. You should probably also change the ownership or permissions for that dir: tommy@pelican ~ $ ls -ld ... drwx------ 2 root root 4096 Nov 8 02:08 ...
The ... directory is fixed now, as is the sudoers perm. Tommy confirms that it works for him. Oh, and FYI, the "-u goverlays" to sudoedit is required, not optional.
sorry to bother again, but htgroup is owned by root, not goverlays.
And I get this for htpasswd :-) rbu@pelican ~ $ sudoedit -u goverlays /var/www/overlays.gentoo.org/htpasswd Sorry, user rbu is not allowed to execute 'sudoedit /var/www/overlays.gentoo.org/htpasswd' as goverlays on pelican.
followup on those two comments for the record, resolved, I missed a comma in the sudoers.
For the records: Requested access for scarabeus, so he can also add/edit/remove users for the sunrise overlay.
scarabeus done for sunrise.
I'd like to request goverlays user access for sping.
did someone reset my password or change the sudo config on that box? I cannot `sudo su - goverlays' anymore.
rbu: the box is ldap-enabled now for users, so try your LDAP password.
I don't think bug is needed anymore.
