Fossil Forum

conf import / export of users
Login

conf import / export of users

conf import / export of users

(1.1) By Robert Ladyman (RoJaLa) on 2021-08-28 14:04:58 edited from 1.0 [source]

When I try the following:

$ fossil conf -R /path/to/repo/one.fossil export user FILENAME
$ fossil conf -R /path/to/repo/two.fossil import FILENAME

I get:

SQLITE_AUTH(23): not authorized in "DELETE FROM "user""
Database error: not authorized: {DELETE FROM "user"}

when run as the setup user and

warning: SQLITE_READONLY(8): statement aborts at 37: [REPLACE INTO 
user(uid,login,info,pw,cap,mtime) 
VALUES(nullif(1,0),'repos','','ZxAfMFbmqL','as',now())] attempt to write a   
readonly database

when run as the admin one.

I assume I am doing something wrong in some way. I thought it might be because fossil was SERVE-ing the fossil repo so I stopped that but with the same result.

(2) By Robert Ladyman (RoJaLa) on 2021-08-28 14:16:15 in reply to 1.1 [link] [source]

"When run as the setup user" means logged into the linux account as the user (e.g. repos) who created the file and is listed as the user in fossil

(3.1) By Stephan Beal (stephan) on 2021-08-28 14:46:47 edited from 3.0 in reply to 1.1 [link] [source]

when run as the setup user and ... when run as the admin one.

That difference is very probably coincidental. When accessed locally, no user permissions are checked or enforced.

The second one indicates that your system user cannot write to that file (independent of fossil). The first looks like a bug - i'll check it when i'm back on the computer.

(4) By Stephan Beal (stephan) on 2021-08-28 14:28:46 in reply to 2 [link] [source]

"When run as the setup user" means logged into the linux account as the user (e.g. repos) who created the file and is listed as the user in fossil

When accessing a repo file directly, as opposed to via a server process, fossil never checks any of its own permissions and doesn't need to know your user name for most ops. Direct access to a fossil repo file trumps any and all of fossil's own security measures except one (the one it looks like your first error message has tripped over). i'll get back to you on that in the next hour or so.

(5) By Robert Ladyman (RoJaLa) on 2021-08-28 14:33:12 in reply to 3.0 [link] [source]

Thanks.

A --for-login-group setting for 'init' which auto-copies the users (or just a --copy-users option where the file is local) would save a lot of fashing. After all, when the above export / import works, it's the same.

Is there a reason why there isn't one?

(6.1) By Stephan Beal (stephan) on 2021-08-28 14:47:11 edited from 6.0 in reply to 5 [link] [source]

Is there a reason why there isn't one?

i don't think it can work: one of the components of their password hashes is some random bytes which are specific to that given clone of the repo. If both clones are 1-to-1 copies, created via cp, rather than clones, created via fossil clone, then those random bytes are identical and the hashes will be compatible, but they otherwise won't (at least, not to the best of my recollection).

(7) By Robert Ladyman (RoJaLa) on 2021-08-28 14:48:27 in reply to 6.0 [link] [source]

Ah, I was only thinking only of the login-group case where the user has to exist in a 'cousin' repo in order to be in the group and local password would not matter.

(8) By Stephan Beal (stephan) on 2021-08-28 15:13:19 in reply to 3.1 [link] [source]

The first looks like a bug - i'll check it when i'm back on the computer.

That's now resolved in trunk:

Before patch:
[stephan@nuc:~/fossil/libfossil]$ fossil conf -R ../x.f import ../x
SQLITE_AUTH(23): not authorized in "DELETE FROM "user""
Database error: not authorized: {DELETE FROM "user"}

After patch:
[stephan@nuc:~/fossil/libfossil]$ fossil conf -R ../x.f import ../x
[stephan@nuc:~/fossil/libfossil]$ 

The second error you're seeing:

warning: SQLITE_READONLY(8): statement aborts at 37: [REPLACE INTO 
user(uid,login,info,pw,cap,mtime) 
VALUES(nullif(1,0),'repos','','ZxAfMFbmqL','as',now())] attempt to write a   
readonly database

is from insufficient filesystem-level permissions (not fossil's doing). The user requires write permission to the db file and its containing directory (for the sqlite3 log file).

(9) By Robert Ladyman (RoJaLa) on 2021-08-28 15:19:58 in reply to 8 [link] [source]

Thanks

I hadn't thought about the log file - I had file permissions via chmod but had not considered the log.

(10) By Stephan Beal (stephan) on 2021-08-28 15:23:08 in reply to 9 [link] [source]

I had file permissions via chmod but had not considered the log.

FWIW, that's a fairly common mistake. Probably everyone here except for Richard (sqlite3's father) has tripped over that a time or three.

(11) By Robert Ladyman (RoJaLa) on 2021-08-28 15:46:51 in reply to 8 [link] [source]

OK, the import works but I cannot log in with the password. Is that expected behaviour? (if it will work with login-group later, that'll be fine).

I exported from both repos following the import and ran a diff: passwords and user-names in the export files are identical.

(12) By Robert Ladyman (RoJaLa) on 2021-08-28 16:05:30 in reply to 11 [link] [source]

I make the cousin repo part of the login-group of the first repo, but it's still not possible to log in as the user with the correct password.

(13) By Stephan Beal (stephan) on 2021-08-28 16:08:07 in reply to 11 [link] [source]

passwords and user-names in the export files are identical.

That's expected and why they don't work. When fossil hashes the incoming password to compare it to the user table, the hash is different because of the random bytes mentioned in a previous response. Fossil does not record passwords, only the hashes of several pieces of information, part of which is the password and part of which is specific to the given repo clone. There is no direct method for doing a user transfer which will carry over the working passwords, and indirect methods require replacing the per-clone random bytes (its "hash secret" ) into each target repo (something we neither condone nor provide a feature for).

(14) By Stephan Beal (stephan) on 2021-08-28 16:10:34 in reply to 12 [link] [source]

I make the cousin repo part of the login-group of the first repo, but it's still not possible to log in as the user with the correct password.

IIRC (but my login group experience is very limited and this might be incorrect) the password must be set/changed on one of the group members after the group nodes are added.

(15.2) By Robert Ladyman (RoJaLa) on 2021-08-28 16:38:39 edited from 15.1 in reply to 13 [link] [source]

Argh. Heh.

OK, let me see if I understand this.

I cannot log into the derived-user repo with the name and password as imported.

However, if I log into the original repo (served by the same fossil program via --repo-list), I find I then have access without logging in, to the derived repo.

If I log out from either, I am logged out from both.

Listing the users of the derived repo, it lacks 'anonymous' and 'reader' users and the setup user. Having the repo leave the login-group results the same list of users.

I suspect I am misunderstanding the login-group idea as a single shared user table.

Edit:

Reading the login-group command it says that I can access other members of a login group if I am logged into any one of them, but the above implies that it has to be the 'master' one that a user is logged into, or that I have to hand set-up users in new repos (as an aside, I cannot see how to get the cli login-group command to understand which repo to operate on - it has a 'join REPO' but how does it know which one is the joiner?)

(16) By Stephan Beal (stephan) on 2021-08-28 16:48:38 in reply to 15.1 [link] [source]

I cannot log into the derived-user repo with the name and password as imported.

Definitely not - the password hashes are invalid in the target repo because of the per-repo "secret."

I suspect I am misunderstanding the login-group idea as a single shared user table.

It's definitely not a shared table, but a list of members, each of which has its user table updated when any member is updated. My very incomplete understanding of login groups is that changing a password on one member will update the password in each member (using each member's hash secret, so the table entries will differ). Aside from that, i don't know off hand whether they offer any features.

Listing the users of the derived repo, it lacks 'anonymous' and 'reader' users and the setup user. Leaving the login-group has the same list of users.

Reader and anonymous belong to a small list of builtin users. The initial setup user is whoever created the repo and i don't believe (but haven't verified (and am on a tablet again so cannot quickly check)) that the setup permissions are exported.

As to your other questions, i'm not familiar enough with login groups to answer with any confidence.

(17) By Robert Ladyman (RoJaLa) on 2021-08-28 17:07:51 in reply to 16 [link] [source]

Stephen - many thanks for your patience and help. I shall have to experiment I think: the login-groups seems a bit of a tack-on.

I suspect that login-groups / lack of central authentication will be a show-stopper for us, at least for https access - we have approximately 200 projects and add a few more each month, all with the same set of users.

I suspect our needs might be better served by ssh access instead - thanks once again for helping and for the bug-fix.