Custom Query (196 matches)

SSLUserName is an evil kludge in our global configuration that interferes with mod_auth_optional, complicates debugging of authentication problems, and cannot be disabled on a per-user basis once enabled globally. We need to get rid of it.

To quote from the scripts-commits@ thread on this issue:

andersk (r409 commit):

Remove SSLUserName, because mod_auth_sslcert is better and having the wrong REMOTE_USER set is confusing.

presbrey:

Its fine if you want to change that behavior from now on but you should certainly leave the old setting for everyone else who quite possibly depend on the old format of the value in the code of their scripts. This is a common issue with global configs.

andersk:

I had done a quick survey of the way REMOTE_USER was used on our vhosts, and didn't notice any obvious problems. We have always been telling users to use SSL_CLIENT_S_DN_Email, anyway, and the fact that REMOTE_USER happened to contain the same value was undocumented. Obviously I can't check every use and there could be new problems, but they will be reported and quickly solved, just like when various PHP extensions were disabled.

(This highlights the need for a good way to inform our users of configuration changes. Is scripts-announce still a useful list to send them to?)

Now that we have more powerful Apache modules for SSL authentication, the SSLUserName hack only gets in the way. For example, with mod_auth_sslcert's AuthSSLCertStripSuffix enabled along with AuthOptional?, I believe that a user with a valid certificate that doesn't match the suffix will still get the REMOTE_USER left over from SSLUserName even though they shouldn't. It's also a pain for debugging that the only side effects of authentication not being properly set up are a @MIT.EDU appended to REMOTE_USER, and mysterious failures when you try to use Apache-level authorization.

I see that you went and reverted my change on the two servers, without making an svn commit. It's fine to let changes lie around uncommited for a little while, but please send email when you do so. Unless you can point to something specific that broke, I'm going to redisable SSLUserName some time tomorrow.

presbrey:

Removing the SSLUserName directive results in a blank REMOTE_USER variable for anyone who hasn't set "AuthType? SSLCert" even when "SSLVerifyClient require" is set.

Surveying the vhosts doesn't quit do it. This change affects everyone on the scripts and scripts-cert hosts as well.

quentin:

I know I'm using REMOTE_USER on one of my sites; rather, I'm using Trac's default handling of REMOTE_USER.

andersk:

But that's part of my point--the scripts server shouldn't be authenticating visitors to scripts that didn't explicitly ask for it. If Trac honors REMOTE_USER by default, then it should be up to the owner to say what a user is, not our global configuration.

Note that, although you can specify SSLUserName in .htaccess if you know you want it, there is no way to _unset_ it if you don't!

quentin:

I don't think it's a good idea to make a non-backwards-compatible change to the way we handle it.

andersk:

I was not aware that people were depending on this broken behavior, so I agree that the change should probably be handled a bit more carefully. Do you think it would be sufficient for this to be part of a mail to scripts-announce, or do you have other suggestions for alerting users?

Regardless of how users are notified, temporarily breaking some scripts that were written with bad assumptions is inevitable. But I think the impact here will be minimal and I'm willing to deal with a few extra support requests.

quentin:

Can I still achieve the same results by configuring mod_auth_sslcert? I don't want authz, just authn.

andersk:

There are plenty of options:

• You can always set SSLUserName SSL_CLIENT_S_DN_Email in .htaccess.
• Or, with the normal

  AuthType SSLCert
  Require valid-user
  

  you'll get REMOTE_USER=quentin.
  • If you don't want to forbid visitors without certificates, add

    AuthSSLCertAuthoritative off
    AuthOptional on
    

  • If you need the REMOTE_USER=quentin@… format, add

    AuthSSLCertStripSuffix ''
    

• Alternatively, you can use SSL_CLIENT_S_DN_Email directly instead of assuming that REMOTE_USER will be the same thing.

Below is signup-sql failing on a locker because it's not attached.

The guilty code is this in signup-sql:

    echo OK.  A MySQL account will be created for a locker of your choice that
    echo you control.  Please enter the name of the selected locker below.
    echo "(For the locker /mit/sipb, you would enter sipb)."
    printf "Locker name: "
    read lname
    lroot="/mit/$lname" 

and a later line that tries to use $lroot (==/mit/stuff).

Rather, this section should do what signup-minimal does:

        while true; do
	    printf "Locker name: "
	    read lname
	    if attach "$lname"; then
		break
	    fi
	    echo "$lname is not a valid locker name."
        done
        lroot="/mit/$lname"

which has the double benefit of attaching the locker and making sure it's attachable / an actual locker name.

athena$ signup-sql

== Welcome to the sql.mit.edu signup process ==

For documentation, including a link to the Athena rules of use,
see <http://sql.mit.edu>.

Please report problems with this signup process to sql@mit.edu.

Are you performing this signup for:
1. Your personal Athena account
2. A locker that you control (a club, a course, etc)
If you do not understand this question, you should answer '1'.
Please enter either '1' or '2' (without quotes): 2

OK. A MySQL account will be created for a locker of your choice that
you control. Please enter the name of the selected locker below.
(For the locker /mit/sipb, you would enter sipb).
Locker name: stuff
attach: /afs/athena.mit.edu/contrib/scripts attached to /mit/scripts for filesystem scripts
mkdir: "/mit/stuff/.scripts-signup": Permission denied

ERROR:
It appears as though you do not have write access to the locker <stuff>.
Contact scripts@mit.edu if you are unable to solve the problem.

It's poor that users outside MIT or who otherwise haven't installed the MIT CA to be trusted get warnings when they visit scripts pages. We can get a cert for <$20/yr for scripts.mit.edu, and for $200/yr (maybe less) for *.scripts.