Fossil SCM

Assorted small improvements to the new http-over-ssh.md doc.

wyoung 2021-09-18 01:37 trunk
Commit d8f470757e9ae126d7bd4324492e9740adf4d4bab34e085d980e0e03cae41588
Parent be8ed971f9e6402…
1 file changed +45 -28
~ www/server/any/http-over-ssh.md
M www/server/any/http-over-ssh.md
+45 -28
--- www/server/any/http-over-ssh.md
+++ www/server/any/http-over-ssh.md
@@ -1,8 +1,8 @@
11
 # Forcing Use of Fossil’s RBAC over SSH
22
3
-Andy Bradford once posted a [clever solution][sshfc] to the problem of
3
+Andy Bradford posted a [clever solution][sshfc] to the problem of
44
 Fossil’s RBAC system [being ignored](../../caps/#webonly) over `ssh://`
55
 URLs: use OpenSSH’s `ForceCommand` feature to route the sync transfer
66
 protocol data over `fossil http` rather than `fossil test-http`.
77
88
 The setup for this is complicated, but it’s a worthy option when you
@@ -48,10 +48,17 @@
4848
 ```
4949
5050
 This would permit only Edie the System Administrator to bypass this
5151
 mechanism.
5252
53
+If you have a user that needs both interactive SSH shell access *and*
54
+Fossil access, exclude that user from the `Match` rule and use Fossil’s
55
+normal `ssh://` URL scheme for those cases. This user will bypass the
56
+Fossil RBAC, but they effectively have Setup capability on those
57
+repositories anyway by having full read/write access to the DB files via
58
+the shell.
59
+
5360
5461
 ## 2. Rewrite the sync command with that wrapper <a id="wrapper"></a>
5562
5663
 When Fossil syncs over SSH, it attempts to launch a remote Fossil
5764
 instance with certain parameters in order to set up the HTTP-based sync
@@ -89,11 +96,13 @@
8996
 selected by “`Match`” block above are dedicated to using only Fossil
9097
 in this setup, this restriction shouldn’t present a practical problem.
9198
9299
 The script’s shebang line assumes `/bin/sh` is POSIX-compliant, but that
93100
 is not the case everywhere. If the script fails to run on your system,
94
-try changing this line to point at `bash`, `dash`, `ksh`, or `zsh`.
101
+try changing this line to point at `bash`, `dash`, `ksh`, or `zsh`. Also
102
+check the absolute paths for local correctness: is `/bin/basename`
103
+installed on your system, for example?
95104
96105
 Under this scheme, you clone with a command like:
97106
98107
 $ fossil clone ssh://HOST/repo.fossil
99108
@@ -101,54 +110,62 @@
101110
 to your local machine under the same name and open it into a “`repo/`”
102111
 subdirectory. Notice that we didn’t have to give the `museum/` part of
103112
 the path: it’s implicit per point #3 above.
104113
105114
 This presumes your local user name matches the remote user name. Unlike
106
-with `http[s]://` URLs, you don’t have to provide the `USER@` part,
107
-since this scheme doesn’t permit anything like anonymous cloning. Only
115
+with `http[s]://` URLs, you don’t have to provide the `USER@` part to
116
+get authenticated access
117
+since this scheme doesn’t permit anonymous cloning. Only
108118
 if two names are different do you need to add the `USER@` bit to the
109119
 URL.
110120
111121
112
-## 3. Accept externally-supplied user names <a id="remote-user"></a>
113
-
114
-Fossil only pays attention to the `REMOTE_USER` environment variable in
115
-certain contexts, of which “`fossil http`” is not one. You have to give
116
-the following command on each repository where you want to allow this:
117
-
118
-``` shell
119
- echo "INSERT OR REPLACE INTO config VALUES ('remote_user_ok',1,strftime('%s','now'));" |
120
- fossil sql -R museum/repo.fossil
121
-```
122
-
123
-## 4. Set permissions <a id="perms"></a>
122
+## 3. Set permissions <a id="perms"></a>
124123
125124
 This scheme assumes that the users covered by the `Match` rule can read
126125
 the wrapper script from where you placed it and execute it, and that
127126
 they have read/write access on the directory where the Fossil
128127
 repositories are stored.
129128
130129
 You can achieve all of this on a Linux box with:
131130
132131
 ``` shell
133
-sudo adduser fossil
134
-for u in alice bob carol dave ; do
135
- sudo adduser $u
136
- sudo gpasswd -a fossil $u
137
-done
138
-sudo -i -u fossil
139
-chmod 710 .
140
-mkdir -m 750 bin
141
-mkdir -m 770 museum
142
-ln -s /usr/local/bin/fossil bin
132
+ sudo adduser fossil
133
+ for u in alice bob carol dave ; do
134
+ sudo adduser $u
135
+ sudo gpasswd -a fossil $u
136
+ done
137
+ sudo -i -u fossil
138
+ chmod 710 .
139
+ mkdir -m 750 bin
140
+ mkdir -m 770 museum
141
+ ln -s /usr/local/bin/fossil bin
143142
 ```
144143
145144
 You then need to copy the Fossil repositories into `~fossil/museum` and
146
-make them writable by group `fossil` and [permit
147
-`REMOTE_USER`](#remote-user) on each one.
145
+make them readable and writable by group `fossil`. These repositories
146
+presumably already have Fossil users configured, with the necessary
147
+[user capabilities](../../caps/), the point of this article being to
148
+show you how to make Fossil-over-SSH pay attention to those caps.
149
+
150
+You must also permit use of `REMOTE_USER` on each shared repository.
151
+Fossil only pays attention to this environment variable in certain
152
+contexts, of which “`fossil http`” is not one. Run this command against
153
+each repo to allow that:
154
+
155
+``` shell
156
+ echo "INSERT OR REPLACE INTO config VALUES ('remote_user_ok',1,strftime('%s','now'));" |
157
+ fossil sql -R museum/repo.fossil
158
+```
159
+
160
+Now you can configure SSH authentication for each user. Since Fossil’s
161
+password-saving feature doesn’t work in this case, I suggest setting up
162
+SSH keys via `~USER/.ssh/authorized_keys` since the SSH authentication
163
+occurs on each sync, which Fossil’s default-enabled autosync setting
164
+makes frequent.
148165
149166
 Equivalent commands for other OSes should be readily discerned from the
150167
 script above.
151168
152169
 [sshfc]: forum:/forumpost/0d7d6c3df41fcdfd
153170
154171
 <div style="height:50em" id="this-space-intentionally-left-blank"></div>
155172
--- www/server/any/http-over-ssh.md
+++ www/server/any/http-over-ssh.md
@@ -1,8 +1,8 @@
1 # Forcing Use of Fossil’s RBAC over SSH
2
3 Andy Bradford once posted a [clever solution][sshfc] to the problem of
4 Fossil’s RBAC system [being ignored](../../caps/#webonly) over `ssh://`
5 URLs: use OpenSSH’s `ForceCommand` feature to route the sync transfer
6 protocol data over `fossil http` rather than `fossil test-http`.
7
8 The setup for this is complicated, but it’s a worthy option when you
@@ -48,10 +48,17 @@
48 ```
49
50 This would permit only Edie the System Administrator to bypass this
51 mechanism.
52
 
 
 
 
 
 
 
53
54 ## 2. Rewrite the sync command with that wrapper <a id="wrapper"></a>
55
56 When Fossil syncs over SSH, it attempts to launch a remote Fossil
57 instance with certain parameters in order to set up the HTTP-based sync
@@ -89,11 +96,13 @@
89 selected by “`Match`” block above are dedicated to using only Fossil
90 in this setup, this restriction shouldn’t present a practical problem.
91
92 The script’s shebang line assumes `/bin/sh` is POSIX-compliant, but that
93 is not the case everywhere. If the script fails to run on your system,
94 try changing this line to point at `bash`, `dash`, `ksh`, or `zsh`.
 
 
95
96 Under this scheme, you clone with a command like:
97
98 $ fossil clone ssh://HOST/repo.fossil
99
@@ -101,54 +110,62 @@
101 to your local machine under the same name and open it into a “`repo/`”
102 subdirectory. Notice that we didn’t have to give the `museum/` part of
103 the path: it’s implicit per point #3 above.
104
105 This presumes your local user name matches the remote user name. Unlike
106 with `http[s]://` URLs, you don’t have to provide the `USER@` part,
107 since this scheme doesn’t permit anything like anonymous cloning. Only
 
108 if two names are different do you need to add the `USER@` bit to the
109 URL.
110
111
112 ## 3. Accept externally-supplied user names <a id="remote-user"></a>
113
114 Fossil only pays attention to the `REMOTE_USER` environment variable in
115 certain contexts, of which “`fossil http`” is not one. You have to give
116 the following command on each repository where you want to allow this:
117
118 ``` shell
119 echo "INSERT OR REPLACE INTO config VALUES ('remote_user_ok',1,strftime('%s','now'));" |
120 fossil sql -R museum/repo.fossil
121 ```
122
123 ## 4. Set permissions <a id="perms"></a>
124
125 This scheme assumes that the users covered by the `Match` rule can read
126 the wrapper script from where you placed it and execute it, and that
127 they have read/write access on the directory where the Fossil
128 repositories are stored.
129
130 You can achieve all of this on a Linux box with:
131
132 ``` shell
133 sudo adduser fossil
134 for u in alice bob carol dave ; do
135 sudo adduser $u
136 sudo gpasswd -a fossil $u
137 done
138 sudo -i -u fossil
139 chmod 710 .
140 mkdir -m 750 bin
141 mkdir -m 770 museum
142 ln -s /usr/local/bin/fossil bin
143 ```
144
145 You then need to copy the Fossil repositories into `~fossil/museum` and
146 make them writable by group `fossil` and [permit
147 `REMOTE_USER`](#remote-user) on each one.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
148
149 Equivalent commands for other OSes should be readily discerned from the
150 script above.
151
152 [sshfc]: forum:/forumpost/0d7d6c3df41fcdfd
153
154 <div style="height:50em" id="this-space-intentionally-left-blank"></div>
155
--- www/server/any/http-over-ssh.md
+++ www/server/any/http-over-ssh.md
@@ -1,8 +1,8 @@
1 # Forcing Use of Fossil’s RBAC over SSH
2
3 Andy Bradford posted a [clever solution][sshfc] to the problem of
4 Fossil’s RBAC system [being ignored](../../caps/#webonly) over `ssh://`
5 URLs: use OpenSSH’s `ForceCommand` feature to route the sync transfer
6 protocol data over `fossil http` rather than `fossil test-http`.
7
8 The setup for this is complicated, but it’s a worthy option when you
@@ -48,10 +48,17 @@
48 ```
49
50 This would permit only Edie the System Administrator to bypass this
51 mechanism.
52
53 If you have a user that needs both interactive SSH shell access *and*
54 Fossil access, exclude that user from the `Match` rule and use Fossil’s
55 normal `ssh://` URL scheme for those cases. This user will bypass the
56 Fossil RBAC, but they effectively have Setup capability on those
57 repositories anyway by having full read/write access to the DB files via
58 the shell.
59
60
61 ## 2. Rewrite the sync command with that wrapper <a id="wrapper"></a>
62
63 When Fossil syncs over SSH, it attempts to launch a remote Fossil
64 instance with certain parameters in order to set up the HTTP-based sync
@@ -89,11 +96,13 @@
96 selected by “`Match`” block above are dedicated to using only Fossil
97 in this setup, this restriction shouldn’t present a practical problem.
98
99 The script’s shebang line assumes `/bin/sh` is POSIX-compliant, but that
100 is not the case everywhere. If the script fails to run on your system,
101 try changing this line to point at `bash`, `dash`, `ksh`, or `zsh`. Also
102 check the absolute paths for local correctness: is `/bin/basename`
103 installed on your system, for example?
104
105 Under this scheme, you clone with a command like:
106
107 $ fossil clone ssh://HOST/repo.fossil
108
@@ -101,54 +110,62 @@
110 to your local machine under the same name and open it into a “`repo/`”
111 subdirectory. Notice that we didn’t have to give the `museum/` part of
112 the path: it’s implicit per point #3 above.
113
114 This presumes your local user name matches the remote user name. Unlike
115 with `http[s]://` URLs, you don’t have to provide the `USER@` part to
116 get authenticated access
117 since this scheme doesn’t permit anonymous cloning. Only
118 if two names are different do you need to add the `USER@` bit to the
119 URL.
120
121
122 ## 3. Set permissions <a id="perms"></a>
 
 
 
 
 
 
 
 
 
 
 
123
124 This scheme assumes that the users covered by the `Match` rule can read
125 the wrapper script from where you placed it and execute it, and that
126 they have read/write access on the directory where the Fossil
127 repositories are stored.
128
129 You can achieve all of this on a Linux box with:
130
131 ``` shell
132 sudo adduser fossil
133 for u in alice bob carol dave ; do
134 sudo adduser $u
135 sudo gpasswd -a fossil $u
136 done
137 sudo -i -u fossil
138 chmod 710 .
139 mkdir -m 750 bin
140 mkdir -m 770 museum
141 ln -s /usr/local/bin/fossil bin
142 ```
143
144 You then need to copy the Fossil repositories into `~fossil/museum` and
145 make them readable and writable by group `fossil`. These repositories
146 presumably already have Fossil users configured, with the necessary
147 [user capabilities](../../caps/), the point of this article being to
148 show you how to make Fossil-over-SSH pay attention to those caps.
149
150 You must also permit use of `REMOTE_USER` on each shared repository.
151 Fossil only pays attention to this environment variable in certain
152 contexts, of which “`fossil http`” is not one. Run this command against
153 each repo to allow that:
154
155 ``` shell
156 echo "INSERT OR REPLACE INTO config VALUES ('remote_user_ok',1,strftime('%s','now'));" |
157 fossil sql -R museum/repo.fossil
158 ```
159
160 Now you can configure SSH authentication for each user. Since Fossil’s
161 password-saving feature doesn’t work in this case, I suggest setting up
162 SSH keys via `~USER/.ssh/authorized_keys` since the SSH authentication
163 occurs on each sync, which Fossil’s default-enabled autosync setting
164 makes frequent.
165
166 Equivalent commands for other OSes should be readily discerned from the
167 script above.
168
169 [sshfc]: forum:/forumpost/0d7d6c3df41fcdfd
170
171 <div style="height:50em" id="this-space-intentionally-left-blank"></div>
172

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button