Re: [fossil-users] New command proposal?
Thus said David Mason on Thu, 25 Jul 2013 18:16:08 -0400: command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... where the name after gate defines the fossil user that this represents, and the ... are the public keys from the particular users. Should this instead represent/identify the remote SSH client? Cannot a remote SSH client have multiple Fossil usernames that might be spread out among the many potential fossils that will live in ~fossilcm/fossils? Also, do you consider it important for the ``fossil gate'' command to impose additional restrictions based upon the username listed? For example, given an entry: command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... Would the gate prevent otheruser from even attempting to access a subset of all the possible fossils in ~fossilcm/fossil? (see below for an example) fossil clone ssh://fossilcm@fossilhost/one.fossil one.fossil and it would only validate against the public key that that user has. This way the remote user can't access any files other than the fossils in that directory. This part, at least, can be accomplished already using this branch: http://www.fossil-scm.org/index.html/timeline?r=ssh-shared-account And the following simple shell script: $ cat fossilgate.sh #!/bin/sh set -- $SSH_ORIGINAL_COMMAND while [ $# -gt 1 ]; do shift; done exec /usr/local/bin/fossil http ./fossils/$1 Of course key management is manual (as you suggested would be the case in the simple setup). There are no file level restrictions in place (as I asked above), only Fossil Privileges and Capabilities. Basically, this allows one to configure a command: command=./fossilgate.sh,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ... And then one can clone using: $ fossil clone -l amb ssh://fossilcm@remote/one.fossil one.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http one.fossil Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 536 bytes sent, 1154 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: f4e6229ef4d633a47de719d7bcea81704e746cc9 admin-user: amb (password is 9fdd1d) If one wanted to extend it further to do fossil name based checking: command=./fossilgate.sh otheruser,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ... $ cat fossilgate.sh #!/bin/sh SSHUSER=$1 set -- $SSH_ORIGINAL_COMMAND while [ $# -gt 1 ]; do shift; done if grep ^$1\$ ./$SSHUSER.fossils /dev/null then exec /usr/local/bin/fossil http ./fossils/$1 fi echo INVALID FOSSIL $1 REQUESTED FOR $SSHUSER 2 And if I try to access something that is not in ./otheruser.fossils, I'll get an error: $ fossil clone -l amb ssh://fossilcm@remote/two.fossil two.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http two.fossil INVALID FOSSIL two.fossil REQUESTED FOR otheruser server did not reply And in the case where fossil name restrictions apply, and I request an allowed fossil, Fossil Privileges still apply: $ fossil clone -l amb ssh://guest@remote/three.fossil three.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http three.fossil Round-trips: 2 Artifacts sent: 0 received: 1 Error: login failed missing or incorrect password for user amb How far is this from what you think would be useful at this point? Andy -- TAI64 timestamp: 400051f6065a ___ 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] New command proposal?
Thus said Alan Barrett on Mon, 29 Jul 2013 08:29:37 +0200: Regardless of whether this is a good idea or not, please do not call it fossil gate. Please give it a name that alerts the user to the fact that it's very closely tied to ssh. Understood. At this point, it is really just a concept (even though I have a working example). I'm not even sure that the tool should be part of fossil proper, since it really falls outside the realm of SCM and doesn't really need fossil to do its work. So it can be called whatever makes sense. I imagine, also, that there might be any number of similar tools that crop up doing similar things, but perhaps with different restrictions. Andy -- TAI64 timestamp: 400051f60fe0 ___ 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] New command proposal?
It appears that gitolite works much like mercurial-server. What I would expect (I haven't set up fossil yet, because I need this functionality) is that the authorized_keys file for the fossilcm user would have: command=/home/fossilcm/bin/fossil gate admin ssh-rsa ... command=/home/fossilcm/bin/fossil gate someuser ssh-rsa ... command=/home/fossilcm/bin/fossil gate amb ssh-rsa ... command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... where the name after gate defines the fossil user that this represents, and the ... are the public keys from the particular users. Then fossil would do whatever the remote command is with LOGIN set to user, e.g., amb, so that whatever permissions amb has to the particular xxx.fossil file would apply. All the fossils would reside in a directory, e.g. ~/fossils and the remote user would say something like: fossil clone ssh://fossilcm@fossilhost/one.fossil one.fossil and it would only validate against the public key that that user has. This way the remote user can't access any files other than the fossils in that directory. In the simplest version of this, the administrator of the fossilcm account would have to manually add user amb's public key to fossilcm's authorized_keys file and add the command= to the front of it (but I outline below a very simple way to allow this to be done remotely after the first one is set up by the admin). mercurial-server automates this via a commit/push hook on a special repository so that keys get automatically added to the authorized_keys file. Their setup is more complicated than necessary, given existing fossil controls. I would simply set it up as follows: ~fossilcm/bin: fossil - the executable ~fossilcm/.ssh: authorized_keys - auto generated by changes to the admin fossil ~fossilcm/fossils: fossil-admin.fossil - the special repository one.fossil - user accesible fossils two.fossil three.fossil the fossil-admin repository would simply contain the ssh pub files for the users allowed to access any of the controlled fossils: admin.pub someuser.pub amb.pub otheruser.pub and all the permission would be handled by the normal fossil commands against the set of users defined in the fossil-admin fossil - in this case: admin, someuser, amb, otheruser. (Presumably only admin is allowed to commit to fossil-admin.) You could make the fossil-admin.fossil more complex to make the permissions controlled by the ssh key as well, but if I understand fossil, that's already well handled by existing mechanisms. Sorry, that's long, but I think complete and simple. If not clear, please ask for clarification. This is functionality that I *REALLY* want, but I don't know enough about fossil and the code base to make it happen. Thanks ../Dave ___ 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] New command proposal?
Thus said Rene on Sun, 21 Jul 2013 00:00:01 +0200: A forced command is in place and it can only be fossil http.This will check if it is started via ssh and then look in the environment to see if the request was fossil gate myotherdb. For now, I think I will abandon the idea that this type of functionality should be present in fossil. I imagine that there could be any number of tools that will crop up that will do various things once the SSH changes are complete (which, I hope they are at this point). So for now, I think I'll write this as a standalone utility (perhaps call it fossil-gate). As I indicated earlier, this could easily be accomplished with a shell script, so making it part of fossil may not be germane to fossil itself. Unless someone vehemently argues to have it be part of fossil, consider the suggestion withdrawn. :-) Andy -- TAI64 timestamp: 400051eb7dfd ___ 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] New command proposal?
On Sat, Jul 20, 2013 at 3:23 PM, Andy Bradford amb-fos...@bradfords.orgwrote: [snip] I'm trying to accomplish what I believe Matt Welland was suggesting it do, which I did like. Basically, if I have an SSH account named ``fossil'' on my server, I can use it to server out as many fossils as I like to any given SSH key connecting to the ``fossil'' account. I think the ultimate usage I envision might be super-set of what Andy is describing but I'm not sure. Would the proposed mechanism enable the usage model I describe below? My desire is to have many users supported via a single account. Users upload their public key to the system. There is a single account they access via ssh/fossil (fossilscm or something like that) but the log in process extracts their user id from the url and authenticates against the public key they uploaded. This means the fossils are protected by a single account and that users can only access the fossil via that account. This is how gitolite works (or at least how it worked when I went through the install process some time ago). This is a many-to-many with access controlled by scripts/lookup tables at the fossilscm account end. Administration consists of: 1. Adding public key/user name combinations 2. Added users to the access lists From the gitolite wiki at http://gitolite.com/gitolite/index.html#what: What is gitolite? Gitolite is an access control layer on top of git. Here are the features that most people see: Use a single unix user (real user) on the server. Provide access to many gitolite users: they are not real users, they do not get shell access. Control access to many git repositories: read access controlled at the repo level, write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags. Can be installed without root access, assuming git and perl are already installed. Authentication is most commonly done using sshd, but you can also use http if you prefer (this may require root access). The forced command on the server will be: command=/usr/bin/fossil gate /tmp/allowed-fossils ssh-rsa ... fossil gate will then inspect SSH_ORIGINAL_COMMAND and extract the requested fossil repo. If the FILENAME contains the requested repo (and perhaps if it is executable and returns successfully), fossil gate will then exec ``fossil http /path/to/repo'' otherwise it will exit with an error. This allows you to use the same client SSH key to access multiple remote fossil accounts using the same remote SSH account. This allows for a 1 to many as opposed to 1 to 1 relationship. It will still be possible for a forced command to be: command=/usr/bin/fossil http /tmp/file.fossil ssh-rsa ... However, this means that you can only ever access that single fossil file using that SSH key and SSH account combination. Thoughts? Andy -- TAI64 timestamp: 400051eb0e0f ___ 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] New command proposal?
Thus said Matt Welland on Sun, 21 Jul 2013 22:16:42 -0700: The ssh key is being used to give access only to the fossil file and yes, the access list would map ssh keys (thus users) to fossils. Just for clarification... access list would map an SSH key user to fossils, but not necessarily grant any Fossil Privileges and Capabilities to the user using that key, correct? Thanks, Andy -- TAI64 timestamp: 400051ecc23a ___ 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] New command proposal?
On Sun, Jul 21, 2013 at 10:09 PM, Andy Bradford amb-sendok-1377061791.goefgfndahogdhegp...@bradfords.org wrote: Notice that I'm able to access multiple fossil files with my SSH key and Fossil account. And, I can install as many SSH keys into the ``guest'' account as I like. This is a many-to-many with access controlled by scripts/lookup tables at the fossilscm account end. So, I can do many-to-many now, what's lacking perhaps is lookup tables. Administration consists of: 1. Adding public key/user name combinations 2. Added users to the access lists Here is where I'm confused. Does this mean that an SSH key identifies the user both to Unix and to Fossil? As for the access list, I assume you mean a mapping of which fossils a given SSH key can actually request? Yes, lookup tables and scripting would be required and that is definitely outside the scope of fossil itself. The ssh key is being used to give access only to the fossil file and yes, the access list would map ssh keys (thus users) to fossils. -- 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
[fossil-users] New command proposal?
Hello, I've been working on a simple fossil command that will integrate with SSH accounts where SSH keys are in use and wonder if there is a formal process for coming up with new subcommand names? Here is what I have at the moment: $ fossil help gate Usage: fossil gate ?FILENAME? fossil gate ?FILENAME? Scans filename for the requested fossil path found in the SSH_ORIGINAL_COMMAND environment variable and runs fossil http path if found. If filename is not present, just run fossil http with the requested path and the operating system will impose restrictions. Any suggestions? Thanks, Andy -- TAI64 timestamp: 400051eafbf8 ___ 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] New command proposal?
On 2013-07-20 23:06, Andy Bradford wrote: Hello, I've been working on a simple fossil command that will integrate with SSH accounts where SSH keys are in use and wonder if there is a formal process for coming up with new subcommand names? Here is what I have at the moment: $ fossil help gate Usage: fossil gate ?FILENAME? fossil gate ?FILENAME? Scans filename for the requested fossil path found in the SSH_ORIGINAL_COMMAND environment variable and runs fossil http path if found. If filename is not present, just run fossil http with the requested path and the operating system will impose restrictions. Any suggestions? Thanks, Andy -- TAI64 timestamp: 400051eafbf8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users I don not understand this. A forced command is in place and it can only be fossil http.This will check if it is started via ssh and then look in the environment to see if the request was fossil gate myotherdb. what are you trying to archive? -- 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] New command proposal?
Thus said Rene on Sun, 21 Jul 2013 00:00:01 +0200: A forced command is in place and it can only be fossil http.This will check if it is started via ssh and then look in the environment to see if the request was fossil gate myotherdb. what are you trying to archive? I'm trying to accomplish what I believe Matt Welland was suggesting it do, which I did like. Basically, if I have an SSH account named ``fossil'' on my server, I can use it to server out as many fossils as I like to any given SSH key connecting to the ``fossil'' account. The forced command on the server will be: command=/usr/bin/fossil gate /tmp/allowed-fossils ssh-rsa ... fossil gate will then inspect SSH_ORIGINAL_COMMAND and extract the requested fossil repo. If the FILENAME contains the requested repo (and perhaps if it is executable and returns successfully), fossil gate will then exec ``fossil http /path/to/repo'' otherwise it will exit with an error. This allows you to use the same client SSH key to access multiple remote fossil accounts using the same remote SSH account. This allows for a 1 to many as opposed to 1 to 1 relationship. It will still be possible for a forced command to be: command=/usr/bin/fossil http /tmp/file.fossil ssh-rsa ... However, this means that you can only ever access that single fossil file using that SSH key and SSH account combination. Thoughts? Andy -- TAI64 timestamp: 400051eb0e0f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
