Re: [fossil-users] Ssh and multiple users on the same ssh account
On 2013-07-15 02:34, David Mason wrote: You might want to look at how mercurial-server works. You set up one remote account that owns the master repository, but then everyone can access e.g. ssh://h...@foo.bar/reponame but each key has a command set up that says who it is that's accessing and then it uses the rules to control what the person can do. The clever thing is that there is a special hgadmin repository that has keys and an access.conf file that essentially says which keys can do what to which repos. So that whoever has write access to the hgadmin repo can edit the access.conf and add/remove keys and then on the push, it creates the authorized_keys that enforces the security/permission model http://www.lshift.net/mercurial-server.html ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Thanks, I thought of something like that to. -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ssh and multiple users on the same ssh account
I looked at andy's patch, but I cannot make a definite conclusion how it works when multiple users share one ssh account service (fossil). For instance: I have an ssh account renez@sunny with Repo x. Andy comes along. I give him a key and an account on repo x. He clones to repo x2 (And here we have a problem if I removed clone from nobody and only andy and me are allowed to clone Then andy can only clone as renez. But this is minor. Because only trusted people can access the account so nobody is still allowed to clone) if Andy does a push to Repo x with fossil push ssh://renez@sunny/scm/x?fossil=bin/fossil I expect/hope/dream that once fossil http starts a login card with Andy's name on it is sent to the server. and not g.urlUser!. Because, for my intent and purposes, that would be wrong. I do see a solution for this and the problem of cloning mentioned before. If I want to work with ssh account sharing then ssh forced commands and extra personal keys are, almost, mandatory. lets view de url ssh://renez@sunny/scm/x with user key rsa-1024 as unlocking the transport mechanism. But not unlocking the repo. Because the ssh key is personal so we would know it's Andy (or someone who stole his key) knocking on the door. We start http with --override-user andy and asked for Andy's (fossil)password (Now that would be a surprise if his key was stolen) Actually what is the sense of having a repo behind ssh If only one user can access it. Your not going to give your key to other persons so they can clone? Well it does make sense when the repo is placed in a shared directory. and users who have an account on that machine can do their work. (Actually that could be though to keep the repo save. you would have to disallow user to bring there own fossil executable. And the fossil executable should be build en md5 and sha1 by trusted person. In this situation my idea could add an extra layer that they could only do fossil.) I don't know if there is actually interest to have it work like that. Having written this email it only seems logical to use g.urlUser I do think that the added functionality can be done in such a way that it will transparent for the intended usage. (because they will not have a force command on their own key. And even then they would let fossil slide by as legitimate usage) -- 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] Ssh and multiple users on the same ssh account
Thus said Rene on Sun, 14 Jul 2013 21:34:06 +0200: I looked at andy's patch, but I cannot make a definite conclusion how it works when multiple users share one ssh account service (fossil). I had given some thought to this particular use case, but it is outside the scope of the original SSH changes I've been making. Right now, the Fossil user is derived from the URL, e.g., ssh://amb@remote/repo.fossil means that the Fossil user will be amb (as will the SSH user). This means that traditional Unix permissions can be used on the remote host to determine who can have actual file permissions to read/write the file, but using ``fossil http repo.fossil'' will also dicate who can actually commit changes. If I understand what you are suggesting is that Fossil user amb can checkout the repo using a Unix user account other than amb to access the file. Theoretically I think this should be possible. All that needs to be done is to some how inform the local Fossil client that the user that it will present once it has an HTTP session is different from the actual underlying Unix account. Actually what is the sense of having a repo behind ssh If only one user can access it. One can use traditional Unix permissions (as you mentioned) to manage who can gain file-level access to the file. For example, /tmp/test.fossil could have permissions of 660 which means only the owner and those who are a member of the group will be able to access it: $ ls -l /tmp/test.fossil -rw-rw 1 amb guest 56320 Jul 14 14:59 /tmp/test.fossil This was actually how I intended to use it. Each person would have their own Unix account *AND* a Fossil account by the same name, and their own SSH key tied to their own account. I can see, however, that in some cases it might be desirable to share the same Unix account using SSH keys, but that was not something I had originally written code for. (Actually that could be though to keep the repo save. you would have to disallow user to bring there own fossil executable. And the fossil executable should be build en md5 and sha1 by trusted person. In this situation my idea could add an extra layer that they could only do fossil.) Yes, you're right, even in the case where Fossil accounts and Unix accounts are the same, it would be desirable to use SSH keys because, as you said, if they have shell access, they can just use their own fossil binary locally. I don't know if there is actually interest to have it work like that. I think there is interest. It wasn't part of my original scope, but I did plan on looking at it later. This will definitely need more thought. I was going to send out my latest patch, which is actually complete as far as I'm concerned at this point. I stripped out all the original SSH handling code and simplified the usage to just ``fossil http /path'' and updated the Usage statement for clone. Should I refrain from sending out the patch until additional thought can be given to a single shared Unix account? Thanks, Andy -- TAI64 timestamp: 400051e31413 ___ 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] Ssh and multiple users on the same ssh account
You might want to look at how mercurial-server works. You set up one remote account that owns the master repository, but then everyone can access e.g. ssh://h...@foo.bar/reponame but each key has a command set up that says who it is that's accessing and then it uses the rules to control what the person can do. The clever thing is that there is a special hgadmin repository that has keys and an access.conf file that essentially says which keys can do what to which repos. So that whoever has write access to the hgadmin repo can edit the access.conf and add/remove keys and then on the push, it creates the authorized_keys that enforces the security/permission model http://www.lshift.net/mercurial-server.html ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
