Re: [fossil-users] ForceCommand SSH key with fossil?
Thus said Rene on Sun, 30 Jun 2013 16:07:44 +0200:
It could be an alternative way. But the urlShell seems to be much
easier!
Thanks, I actually looked at urlShell, but it didn't seem right, or was
confusing, or both.
I've actually made some progress in getting the fossil client to
integrate better with SSH, and believe to have also succeeded in
preserving backwards compatibility with older fossil servers, while
deprecating urlShell at the same time.
I have run into an authentication snag, however, that I have not yet
been able to resolve:
$ /usr/local/bin/fossil ver
This is fossil version 1.22 [5dd5d39e7c] 2012-03-19 12:45:47 UTC
$ /home/amb/bin/fossil ver
This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC
The latter has the modifications I've made which allow one to easily
integrate with SSH (without having any shell dependencies on the remote
system). Specifically, transport_ssh_startup() is no longer needed and
can be removed. The URL path is used to construct the SSH command (as
seen in the output below) in transport_global_startup().
Here is an example:
$ /home/amb/bin/fossil clone ssh://amb@localhost//tmp/test.fossil test.fossil
ssh -e none -T amb@localhost fossil http /tmp/test.fossil
amb@localhost's password: sent: 0 received: 0
Round-trips: 1 Artifacts sent: 0 received: 7
ssh -e none -T amb@localhost fossil http /tmp/test.fossil
amb@localhost's password: sent: 0 received: 7
Round-trips: 2 Artifacts sent: 0 received: 8
Clone finished with 487 bytes sent, 1977 bytes received
Rebuilding repository meta-data...
100.0% complete...
project-id: e5619492ebdf0bf2dddf419544f3ccd230293ab1
admin-user: amb (password is 1afa92)
Great, it works for cloning (after entering my SSH password). It also
works with restricted force command SSH keys (note that the server that
the SSH key dictates is running version 1.22). Also note that I
attempted to request /tmp/another.fossil but the server forced me to
fetch /tmp/test.fossil (as per SSH force command):
$ grep fossil /home/amb/.ssh/authorized_keys
command=/usr/local/bin/fossil http /tmp/test.fossil ssh-rsa
B3NzaC1yc2EDAQABAAABAQDqKI393xubO69Rs+Y6fbnxDpAgX5kTe31qWepFyfu08wxNj5iX57vNIYFIcC7bwKW4EHMakuEIYr2eDzXl3e1pXLzteFESISaZkXrmspNIMRh4oW/3LqV+pGXfimA//YlmbJOMzEHerSCTi+QG0O6LNyvjlZgJmP8dJgc0ktzw6nAVcpdFxwoNa+tQJb+g7wLHGRCsl9uvf6rfdzXVUm/tAtD/TyPITU7Ni2q7aTm/m8YKsXDUif91UP9XUH8phwwEucQa3MagtIcmUKJzrkuwHT+rr2K/0W8vpjO3iq3g7ejONqaTfqEW2Rc5uydYsc1B5IjsmPm0bVkbB3B6ZBxF
amb
$ /home/amb/bin/fossil clone ssh://amb@localhost//tmp/another.fossil test.fossil
ssh -e none -T amb@localhost fossil http /tmp/another.fossil
Round-trips: 1 Artifacts sent: 0 received: 7
ssh -e none -T amb@localhost fossil http /tmp/another.fossil
Round-trips: 2 Artifacts sent: 0 received: 8
Clone finished with 495 bytes sent, 1976 bytes received
Rebuilding repository meta-data...
100.0% complete...
project-id: e5619492ebdf0bf2dddf419544f3ccd230293ab1
admin-user: amb (password is 7ea596)
$ ls -l test.fossil /tmp/*.fossil
-rw-r--r-- 1 amb wheel 58368 Jul 1 00:00 /tmp/another.fossil
-rw-r--r-- 1 amb wheel 60416 Jun 30 18:29 /tmp/test.fossil
-rw-r--r-- 1 amb amb60416 Jul 1 00:19 test.fossil
Now, on to the snag... I can open the cloned repository and commit
changes, but autosync failes due to authorization problems. I'm not
really sure why this doesn't work (the changes I've made are fairly
trivial and I fail to see how they even affect authorization):
$ f op test.fossil
file
...
$ f ci -m new
Autosync: ssh://amb@localhost//tmp/test.fossil
ssh -e none -T amb@localhost fossil http /tmp/test.fossil
Round-trips: 1 Artifacts sent: 0 received: 0
Pull finished with 292 bytes sent, 433 bytes received
New_Version: 7934407cf95c5936eb460a5ce3d166123dbcbdc7
Autosync: ssh://amb@localhost//tmp/test.fossil
ssh -e none -T amb@localhost fossil http /tmp/test.fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Error: not authorized to write
Round-trips: 1 Artifacts sent: 2 received: 0
Sync finished with 633 bytes sent, 465 bytes received
Autosync failed
I don't understand why it thinks my user account is not authorized to
write. It has read/write access to the file. Is there something else
that is missing?
Any pointers?
A patch follows with the changes I've made (needs a little clean up in
actually outputting the newly added options in usage statements):
diff -ur fossil-src-20130618210923.orig/src/clone.c
fossil-src-20130618210923/src/clone.c
--- fossil-src-20130618210923.orig/src/clone.c Tue Jun 18 15:57:11 2013
+++ fossil-src-20130618210923/src/clone.c Sun Jun 30 23:53:17 2013
@@ -105,6 +105,7 @@
int bPrivate = 0; /* Also clone private branches */
if( find_option(private,0,0)!=0 ) bPrivate = SYNC_PRIVATE;
+ clone_ssh_options();
url_proxy_options();
if( g.argc 4 ){
usage(?OPTIONS? FILE-OR-URL NEW-REPOSITORY);
Re: [fossil-users] ForceCommand SSH key with fossil?
On Mon, Jul 01, 2013 at 12:42:11AM -0600, Andy Bradford wrote: Thus said Rene on Sun, 30 Jun 2013 16:07:44 +0200: It could be an alternative way. But the urlShell seems to be much easier! Thanks, I actually looked at urlShell, but it didn't seem right, or was confusing, or both. snip Now, on to the snag... I can open the cloned repository and commit changes, but autosync failes due to authorization problems. I'm not really sure why this doesn't work (the changes I've made are fairly trivial and I fail to see how they even affect authorization): $ f op test.fossil file ... $ f ci -m new Autosync: ssh://amb@localhost//tmp/test.fossil ssh -e none -T amb@localhost fossil http /tmp/test.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 292 bytes sent, 433 bytes received New_Version: 7934407cf95c5936eb460a5ce3d166123dbcbdc7 Autosync: ssh://amb@localhost//tmp/test.fossil ssh -e none -T amb@localhost fossil http /tmp/test.fossil Round-trips: 1 Artifacts sent: 2 received: 0 Error: not authorized to write Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 633 bytes sent, 465 bytes received Autosync failed I don't understand why it thinks my user account is not authorized to write. It has read/write access to the file. Is there something else that is missing? Any pointers? Have you try with server running more recent version ? I remember there was a patch somewhere between version 1.24 and 1.25 that was forcing full right when syncing using ssh://. A patch follows with the changes I've made (needs a little clean up in actually outputting the newly added options in usage statements): snip Nice.. have you send your Contributor aggreement to Mr. Hipp ? http://www.fossil-scm.org/xfer/doc/trunk/www/contribute.wiki I'm very interested to see this kind of security enforcement for the ssh protocol.. With this patch, we can have fossil access via ssh without having full shell access to the server.. Eventually, sync permission could be honor as for http:// since accessing the repo via ssh would not mean anymore to have direct access to the .fossil file. Regards, -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
Thus said Martin Gagnon on Mon, 01 Jul 2013 09:08:54 -0400: Have you try with server running more recent version ? I remember there was a patch somewhere between version 1.24 and 1.25 that was forcing full right when syncing using ssh://. I've tried with both 1.22 and 1.26. Here it is with 1.26 against 1.26: $ fossil push Push to ssh://amb@localhost//tmp/test.fossil ssh -e none -T amb@localhost /home/amb/bin/fossil http /tmp/test.fossil amb@localhost's password: sent: 0 received: 0 Error: not authorized to write Round-trips: 1 Artifacts sent: 0 received: 0 Push finished with 373 bytes sent, 276 bytes received Nice.. have you send your Contributor aggreement to Mr. Hipp ? I have not---guess I'll need to do that if he intends to include my patch directly. The patch isn't complete yet (obviously because authentication is not working), so that gives me some time. I'm very interested to see this kind of security enforcement for the ssh protocol.. With this patch, we can have fossil access via ssh without having full shell access to the server.. Not to mention it does away with strange shell interaction problems (I ran into them the first time I tried to setup SSH), hopefully not introducing other problems. Andy -- TAI64 timestamp: 400051d19784 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why delta manifests?
On Mon, Jul 01, 2013 at 12:08:42AM +0200, Isaac Jurado wrote: After the results, the conclusion is obvious: the generic artifact delta compression is outperforming the delta manifest convention. So the question is, what is the rationale behind delta manifests? After checking Fossil's history, it looks like they were added after artifact delta compression. Which actually seems even more confusing. Delta manifests are not meant to reduce the repository size, but the amount of parsing to be done. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why delta manifests?
On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jul 01, 2013 at 12:08:42AM +0200, Isaac Jurado wrote: After the results, the conclusion is obvious: the generic artifact delta compression is outperforming the delta manifest convention. So the question is, what is the rationale behind delta manifests? After checking Fossil's history, it looks like they were added after artifact delta compression. Which actually seems even more confusing. Delta manifests are not meant to reduce the repository size, but the amount of parsing to be done. That sounds intriguing. What kind of operations can complete without having to load the baseline manifest at all? Cheers. -- Isaac Jurado The noblest pleasure is the joy of understanding Leonardo da Vinci ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
Just FYI, removing the dependency on the shell for ssh access would be *very* much appreciated. Being able to fossil access without full shell access will be fantastic. On Mon, Jul 1, 2013 at 7:51 AM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Martin Gagnon on Mon, 01 Jul 2013 09:08:54 -0400: Have you try with server running more recent version ? I remember there was a patch somewhere between version 1.24 and 1.25 that was forcing full right when syncing using ssh://. I've tried with both 1.22 and 1.26. Here it is with 1.26 against 1.26: $ fossil push Push to ssh://amb@localhost//tmp/test.fossil ssh -e none -T amb@localhost /home/amb/bin/fossil http /tmp/test.fossil amb@localhost's password: sent: 0 received: 0 Error: not authorized to write Round-trips: 1 Artifacts sent: 0 received: 0 Push finished with 373 bytes sent, 276 bytes received Nice.. have you send your Contributor aggreement to Mr. Hipp ? I have not---guess I'll need to do that if he intends to include my patch directly. The patch isn't complete yet (obviously because authentication is not working), so that gives me some time. I'm very interested to see this kind of security enforcement for the ssh protocol.. With this patch, we can have fossil access via ssh without having full shell access to the server.. Not to mention it does away with strange shell interaction problems (I ran into them the first time I tried to setup SSH), hopefully not introducing other problems. Andy -- TAI64 timestamp: 400051d19784 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
If I have an account on the remote machine then autosync succeeds. I have this setup: archlinux running this is fossil version 1.25 [878f7008ab] 2013-05-31 17:41:25 UTC windows xp virtual machine arch fossil create andy.fsl fossil ui andy.fsl (add user zwart604 as developer) win fossil settings ssh-command plink -T fossil clone ssh://renez@arch/andy.fsl?fossil=bin/fossil andyclone.fsl --sshTrace plink -T renez@arch ==Using username renez. Round-trips: 2 Artifacts sent: 0 received: 6 Clone finished with 485 bytes sent, 1294 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 131a4040153ac69a6f4d1108b23f57eccef102b2 admin-user: zwart604 (password is 45004c) mkdir t cd t fossil open ..\andyclone.fsl echo #include stdfio.h a.c fossil add a.c temp\t..\fossil.exe commit -m did this as zwart604 Autosync: ssh://renez@arch/andy.fsl?fossil=bin/fossil plink -T renez@arch Using username renez. Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 290 bytes sent, 286 bytes received ./a.c contains CR/NL line endings. Use --no-warnings or the crnl-glob setting to disable this warning. Commit anyhow (a=all/c=convert/y/N)? a New_Version: 9eeeca09475fc269e49c1864ec9ff5b669e5664a Autosync: ssh://renez@arch/andy.fsl?fossil=bin/fossil plink -T renez@arch == Using username renez. Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 522 bytes sent, 340 bytes received What is annoying is that all the interaction is done with the name of the user who has the ssh-account. like the log is 2 2013-07-01 18:03:02 renez 127.0.0.1 1 2013-06-30 13:36:03 renez Number 2 is not true that came from zwart604 at ip xxx.xxx.xxx.xxx Maybe make the force command command=/usr/local/bin/fossil http /tmp/test.fossil --user zwart604 --ip x.x.x.x ssh-rsa if you have given the key to one person then the key will identify the user $SSH2_CLIENT, extract the IP address of the incoming client, which is the first (of three) value in the string. Or fossil could pick that up form cards sent. or from the environment or from both Why not a mode fossil ssh (which would be a special http) What seems weird if I drop the access of zwart604 to g(Clone) i can still sync and enter new files Is that expected behaviour? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
On Mon, Jul 1, 2013 at 9:16 PM, Rene renew...@xs4all.nl wrote: What seems weird if I drop the access of zwart604 to g(Clone) i can still sync and enter new files Is that expected behaviour? The i (Inbound/write/checkin) permission controls that. Are you able to bypass that permission check? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why delta manifests?
On Mon, Jul 01, 2013 at 05:18:40PM +0200, Isaac Jurado wrote: On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger Delta manifests are not meant to reduce the repository size, but the amount of parsing to be done. That sounds intriguing. What kind of operations can complete without having to load the baseline manifest at all? There are primarily two uses. To find out what artifacts represent control manifests, you have to check them for well-formedness. That means that rebuild is a direct function of the raw, undeltafied size of the repository. Second, you can compute changes between two manifests that use the same base line directly. Third, it cuts the delta chain depth a lot as well. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] File mode information loss following a merge
Hi all, I've just encountered a scenario in which file mode information is lost following a merge. This involves (a) adding an executable file, (b) renaming it in a branch, then (c) merging back into trunk. To replicate, $ repo=tmp $ fossil new $repo.fsl; mkdir $repo; cd $repo $ fossil open ../$repo.fsl $ touch a; chmod +x a $ fossil add a; fossil commit -m Add 'a' $ mv a b $ fossil mv a b $ fossil commit -m Rename 'a' to 'b' --branch moved $ fossil up trunk $ fossil merge moved $ fossil commit -m 'Merge moved.' Note that 'b' is executable in 'moved' but not in 'trunk'. (Encountered on Linux, recreated on OS X with the latest Fossil build.) Best, Marc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
Yes, I dropt it from gjo to g. I now dropped of the g and my windows repo still sync succesful with the master repo. Where zwart604 now has no permissions at all see below the timeline the one at 20:49 is of zwart604 with no permissions on the master one. I probably do something wrong! 2013-07-01 20:49 [0887e49cf5] Leaf: did this as zwart604 (user: zwart604, tags: trunk) 20:48 [9e62c4aafe] did this as zwart604 (user: zwart604, tags: trunk) 19:06 [d5f8fc4fc9] did this as zwart604 (user: zwart604, tags: trunk) 19:03 [6cac74dbb7] did this as zwart604 (user: zwart604, tags: trunk) 19:01 [4576135d8c] did this as zwart604 (user: zwart604, tags: trunk) 18:02 [9eeeca0947] did this as zwart604 (user: zwart604, tags: trunk) On 2013-07-01 21:35, Stephan Beal wrote: On Mon, Jul 1, 2013 at 9:16 PM, Rene renew...@xs4all.nl wrote: What seems weird if I drop the access of zwart604 to g(Clone) i can still sync and enter new files Is that expected behaviour? The i (Inbound/write/checkin) permission controls that. Are you able to bypass that permission check? -- - stephan beal http://wanderinghorse.net/home/stephan/ [1] http://gplus.to/sgbeal [2] Links: -- [1] http://wanderinghorse.net/home/stephan/ [2] http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
On Mon, Jul 1, 2013 at 10:57 PM, Rene renew...@xs4all.nl wrote: see below the timeline the one at 20:49 is of zwart604 with no permissions on the master one. I probably do something wrong! If i'm not mistaken (and i might be - i'm not familiar with the details of fossil's ssh bits), a user running over ssh has all permissions (because that's what fossil uses when run in non-server/CGI mode). If, however, fossil is using its HTTP server over ssh (i don't know whether it does or not does, to be honest), then it should be setting up the permissions properly for the user. Based on my interpretation of your results, a user running over ssh has all permissions, as for a local user. i can't immediately say whether that's expected or not. Sorry, not very helpful :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
On Mon, Jul 1, 2013 at 5:01 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 1, 2013 at 10:57 PM, Rene renew...@xs4all.nl wrote: see below the timeline the one at 20:49 is of zwart604 with no permissions on the master one. I probably do something wrong! If i'm not mistaken (and i might be - i'm not familiar with the details of fossil's ssh bits), a user running over ssh has all permissions (because that's what fossil uses when run in non-server/CGI mode). If, however, fossil is using its HTTP server over ssh (i don't know whether it does or not does, to be honest), then it should be setting up the permissions properly for the user. Based on my interpretation of your results, a user running over ssh has all permissions, as for a local user. i can't immediately say whether that's expected or not. I think you are right. The default behavior when running fossil locally is to let the user do anything requested. Presumably, if the user can run Fossil, then they can also edit the repository database file at will, and so there really isn't any point in trying to enforce permissions in that scenario. When you run the fossil http command, the user identified by each HTTP request is used. However, ssh does not run fossil http, it uses fossil test-http instead (unless Andy has changed that in his local copy). And fossil test-http, since it was originally designed for testing, gives every request Admin privilege, meaning it can do anything it want. I have not been following this thread closely, but perhaps the solution is to change the test-http near lean 296 in http_transport.c to be just http. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
On 2013-07-01 23:01, Stephan Beal wrote:
On Mon, Jul 1, 2013 at 10:57 PM, Rene renew...@xs4all.nl wrote:
see below the timeline the one at 20:49 is of zwart604 with no
permissions on the master one. I probably do something wrong!
If i'm not mistaken (and i might be - i'm not familiar with the
details of fossil's ssh bits), a user running over ssh has all
permissions (because that's what fossil uses when run in
non-server/CGI mode). If, however, fossil is using its HTTP server
over ssh (i don't know whether it does or not does, to be honest),
then it should be setting up the permissions properly for the user.
Based on my interpretation of your results, a user running over ssh
has all permissions, as for a local user. i can't immediately say
whether that's expected or not.
Sorry, not very helpful :/.
--
- stephan beal
http://wanderinghorse.net/home/stephan/ [1]
http://gplus.to/sgbeal [2]
Links:
--
[1] http://wanderinghorse.net/home/stephan/
[2] http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Hm, This is what I see if I do:
C:\temp\techo hallo g.c
C:\temp\t..\fossil.exe add g.c
ADDED g.c
C:\temp\t..\fossil.exe commit -m did this as zwart604
--sshtrace
Autosync: ssh://renez@arch/andy.fsl?fossil=bin/fossil
plink -T renez@arch
Sent: [echo probe-8b38afea112ef8b4a65dfb639b526c2c]
Using username renez.
Got back---
probe-8b38afea112ef8b4a65dfb639b526c2c
---
Sent: [echo probe-7d8a878c308bc5f5ab12fa1baaf3609f]
Got back---
probe-7d8a878c308bc5f5ab12fa1baaf3609f
---
Sent: [bin/fossil test-http andy.fsl]eceived: 0
Got line: [HTTP/1.0 200 OK]
Got line: [Date: Mon, 1 Jul 2013 21:05:21 GMT]
Got line: [Connection: close]
Got line: [X-Frame-Options: SAMEORIGIN]
Got line: [Cache-control: no-cache]
Got line: [Content-Type: application/x-fossil; charset=utf-8]
Got line: [Content-Length: 280]
Got line: []
Reading 280 bytes with 0 on hand... Got 280 bytes
Round-trips: 1 Artifacts sent: 0 received: 0
Pull finished with 290 bytes sent, 480 bytes received
./g.c contains CR/NL line endings. Use --no-warnings or the
crnl-glob setting
to disable this warning.
Commit anyhow (a=all/c=convert/y/N)? a
New_Version: 50122ec07cb3c91d8910105f6a9c8050ddcae4c1
Autosync: ssh://renez@arch/andy.fsl?fossil=bin/fossil
plink -T renez@arch
Sent: [echo probe-d7c9e86da35acc3286ded3db70a416e4]
Using username renez.
Got back---
probe-d7c9e86da35acc3286ded3db70a416e4
---
Sent: [echo probe-f7e5b3ddbb9a59c5c9e6855723a29fde]
Got back---
probe-f7e5b3ddbb9a59c5c9e6855723a29fde
---
Sent: [bin/fossil test-http andy.fsl]eceived: 0
Got line: [HTTP/1.0 200 OK]
Got line: [Date: Mon, 1 Jul 2013 21:05:28 GMT]
Got line: [Connection: close]
Got line: [X-Frame-Options: SAMEORIGIN]
Got line: [Cache-control: no-cache]
Got line: [Content-Type: application/x-fossil; charset=utf-8]
Got line: [Content-Length: 305]
Got line: []
Reading 305 bytes with 0 on hand... Got 305 bytes
Round-trips: 1 Artifacts sent: 2 received: 0
Sync finished with 676 bytes sent, 505 bytes received
C:\temp\t
and the answer is
/*
** Note that the following command is used by ssh:// processing.
**
** COMMAND: test-http
** Works like the http command but gives setup permission to all users.
*/
void cmd_test_http(void){
Th_InitTraceLog();
login_set_capabilities(sx, 0);
g.useLocalauth = 1;
cgi_set_parameter(REMOTE_ADDR, 127.0.0.1);
g.httpIn = stdin;
g.httpOut = stdout;
find_server_repository(0);
g.cgiOutput = 1;
g.fullHttpReply = 1;
cgi_handle_http_request(0);
process_one_web_page(0, 0);
}
--
Rene
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ForceCommand SSH key with fossil?
Thus said Richard Hipp on Mon, 01 Jul 2013 17:23:58 -0400: When you run the fossil http command, the user identified by each HTTP request is used. However, ssh does not run fossil http, it uses fossil test-http instead (unless Andy has changed that in his local copy). And fossil test-http, since it was originally designed for testing, gives every request Admin privilege, meaning it can do anything it want. Bingo! The problem was that I failed to understand the significance of test-http and thought it was simply part of a test that the ``interactive'' shell initialization setup that it went through used to determine if the SSH connection was established. I wondered how the remote ``fossil http'' knew about the fact that the SSH connected user had permission. Thanks for clarifying. Andy -- TAI64 timestamp: 400051d21e57 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
