Option to disable anonymous checkins from CCDB command line tool

[sdobbs]

It would be nice to disable anonymous checkins from the CCDB command line tool in some way. Ideally this would be the default behavior.

Since the name associated with a change is taken from CCDB_USER, many people forget to properly set this (despite sustained nagging), which is beginning to make changes difficult to manage.

[markito3]

Some time ago I added definition of CCDB_USER to the version management system (VMS) base set-up script. See https://github.com/JeffersonLab/build_scripts/commit/49c86772a8fd29d74835e6fa3cdae010e125a5c1 . But not everyone uses this, often for good reason.

[markito3]

There is some code in the CCDB scripts that automatically assign CCDB_USER the value of the USER environment variable if CCDB_USER is not defined. That would practically eliminate "anonymous" contributions, but it is commented out. Dmitry recalls that this was done for Hall B. When they first unpacked CCDB, they had no entries for users in their user access table (in the CCDB database). Because of this the automatic CCDB_USER assignment was causing all write access to fail. It was early on; we commented it out to let anonymous users write. This stance has the advantage that the package works "out of the box" with minimal configuration. But it is causing a problem for us now.

Since the C++ API does not write to the database, we only need to solve the problem for Python.

After discussion with Dmitry, we are proposing a solution for the two cases we have: (1) future releases of CCDB (2) retro-fitting the current release.

(1) future releases of CCDB

We add a script to re-write or otherwise select a "ccdb" command that does the auto-setting of CCDB_USER from USER. Auto-setting only happens if this script is executed post-installation. If it is not executed, then the lax out-of-the-box behavior is obtained. In any case, CCDB_USER will not be disturbed if already set.

(2) retro-fitting the current release

We announce a change: we will disallow anonymous writes in the CCDB user access table. Users that want to write will have to have CCDB_USER set in their environment after this change. To help people do this, we change all standard environment-setting scripts to do the auto-setting of CCDB_USER from USER. Those not using the standard scripts will have to define CCDB_USER for themselves if they want to write.

[sdobbs]

That sounds reasonable. For part (1), perhaps the auto-setting could selectable as a build option, so whether or on it's enabled would be decided at build time?

On Wed, Nov 18, 2015 at 3:58 PM Mark M. Ito notifications@github.com wrote:

There is some code in the CCDB scripts that automatically assign CCDB_USER the value of the USER environment variable if CCDB_USER is not defined. That would practically eliminate "anonymous" contributions, but it is commented out. Dmitry recalls that this was done for Hall B. When they first unpacked CCDB, they had no entries for users in their user access table (in the CCDB database). Because of this the automatic CCDB_USER assignment was causing all write access to fail. It was early on; we commented it out to let anonymous users write. This stance has the advantage that the package works "out of the box" with minimal configuration. But it is causing a problem for us now.

Since the C++ API does not write to the database, we only need to solve the problem for Python.

The proposed solution in two parts: (1) future releases of CCDB (2) retro-fitting the current release.

(1) future releases of CCDB

We add a script to re-write or otherwise select a "ccdb" command that does the auto-setting of CCDB_USER from USER. Auto-setting only happens if this script is executed post-installation. If it is not executed, then the lax out-of-the-box behavior is obtained. In any case, CCDB_USER will not be disturbed if already set.

(2) retro-fitting the current release

We announce a change: we will disallow anonymous writes in the CCDB user access table. Users that want to write will have to have CCDB_USER set in their environment after this change. To help people do this, we change all standard environment-setting scripts to do the auto-setting of CCDB_USER from USER. Those not using the standard scripts will have to define CCDB_USER for themselves if they want to write.

— Reply to this email directly or view it on GitHub https://github.com/JeffersonLab/ccdb/issues/6#issuecomment-157877906.

[DraTeots]

Sean, Something like this.

In details, First, anonymous is a problem of changing MySQL database. SQLite comes with logging disabled (by default). Username isn't used for MySQL readout. So actually only CUE users making changes to our MySQL database should be affected.

Actually, there is nothing to build for python part === 'ccdb' command. 'ccdb' command is ready right after clonning of CCDB. But we will create a script that will switch ccdb command, to set CCDB_USER=USER automatically or not. So at some point it will be like a build step that could be run at CUE versions (or added to deployment automation etc).

Thus:

1. All users who clone CCDB by themselves are probably not affected by the fact that anonymous can't make changes anymore and their CCDB_USER is not set
2. On CUE and our distributions we will call this script and 'ccdb' command will do CCDB_USER=USER
3. At least we will promt "anonymous is disabled, please set CCDB_USER" for everybody else, put it in documentation etc.

[sdobbs]

OK, that makes sense. Thanks for taking care of this!

[DraTeots]

Looks like the plan isn't going as flawless as expected.

_What I thought:_ The logging for SQLite is off => No user privileges are checked for SQLite => All SQLite users are not affected.

_The reality is:_ The logging for SQLite is off, BUT user privileges are checked whenever logging is off/on.

This mean that if we disable anonymous user privileges to write, then all SQLite users will be affected too. So I would propose:

1. Switch anonymous off only after the next CCDB tag is out and installed on CUE.
2. Should we disable privileges check for SQLite?
3. What else?

[markito3]

Talked to Dmitry.

After the mysql is protected against anonymous write, all the subsequently created SQLite files will have the same protection...unless we update the SQLite files, right after they are created, to allow anonymous write. Dmitry is looking into this.