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: 4000000051e31413 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
