[fossil-users] Restrict access on per-directory or per-branch level?
Hi all, is it possible in Fossil to configure read/write, read-only or no-access for users and/or groups on a per-directory or per-branch level like it is possible with e.g. Subversion with its authz file? Greetings, Stefan -- Stefan Bellon ___ 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] Restrict access on per-directory or per-branch level?
On Fri, Dec 28, 2012 at 5:36 AM, Stefan Bellon sbel...@sbellon.de wrote: Hi all, is it possible in Fossil to configure read/write, read-only or no-access for users and/or groups on a per-directory or per-branch level like it is possible with e.g. Subversion with its authz file? When somebody clones the repository,and has a local copy of the repository, then they can do anything they want with that local copy since it is a file they own. Permissions only come into plan when dealing with a remote server. If somebody has push permission, then they can effectively change anything they want since they were previously able to change anything they wanted on their local repository and a push involves transferring all new content from the local repository to the remote repository, without examining that content. The server does track which artifacts are received during each push, with the timestamp of the push, the user ID of the login that did the push, and the IP address on the other end of the push. In this way, users who break any rules can be tracked down and dealt with through human channels. Any malicious changes can be shunned, so the changes can be undone. There is nothing you can do to restrict which files are changed during a push. The idea is that you trust your developers. For servers, on the /Admin/Access setup page, there is an entry field named Public Pages. That field (which is normally blank) can be set to a comma-separated list of GLOB patterns for URLs that unprivileged users are allowed to read even if they would normally not have read permission. The Public Pages glob list is used, for example, to allow unprivileged users to read a few specific documentation or wiki pages without being able to view private source code or sensitive wiki pages. Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] Restrict access on per-directory or per-branch level?
On Fri, 28 Dec, Richard Hipp wrote: When somebody clones the repository,and has a local copy of the repository, then they can do anything they want with that local copy since it is a file they own. Permissions only come into plan when dealing with a remote server. Right. So, of course, the permissions should already restrict what one can clone. [push permission] The idea is that you trust your developers. This is not always possible. Back in our university days we had a stable code branch where only university employees were allowed to commit, but in certain branches, students were allowed to commit their work which was merged into trunk by employees. Students were not allowed to directly commit into trunk. Due to a misconfiguration it was once possible for students to access an area which they shouldn't have access to ... and guess what ... one student indeed managed to break a crucial file of the build. Of course it was possible to repair everything (because everything is under version control), but it was effort and it is nice to avoid such accidents. This is regarding push permission. Of course, the other direction is problematic as well. E.g. if there exists 3rd party code that is used to build the complete product, but for which not each developer has the required license to see it in source form. For servers, on the /Admin/Access setup page, there is an entry field named Public Pages. That field (which is normally blank) can be set to a comma-separated list of GLOB patterns for URLs that unprivileged users are allowed to read even if they would normally not have read permission. The Public Pages glob list is used, for example, to allow unprivileged users to read a few specific documentation or wiki pages without being able to view private source code or sensitive wiki pages. But this only applies to wiki pages? Not to source code (and, for that matter, not to tickets either)? Then we'll have to think about moving to Fossil with our main repositories again. Greetings, Stefan -- Stefan Bellon ___ 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] Restrict access on per-directory or per-branch level?
Stefan Bellon sbel...@sbellon.de wrote: On Fri, 28 Dec, Richard Hipp wrote: When somebody clones the repository,and has a local copy of the repository, then they can do anything they want with that local copy since it is a file they own. Permissions only come into plan when dealing with a remote server. Right. So, of course, the permissions should already restrict what one can clone. They do. It's just that they are at the repository level, not the branch level. But in many senses, a cloned repository *is* a branch. [push permission] The idea is that you trust your developers. This is not always possible. Back in our university days we had a stable code branch where only university employees were allowed to commit, but in certain branches, students were allowed to commit their work which was merged into trunk by employees. Students were not allowed to directly commit into trunk. So do that with repositories. Create a stable repository that only employees can commit to. Let students create their own repositories, or (if you feel the need) create a different one they can commit to. Then have employees merge changes from students into the trunk repository using an appropriate mechanism. This is regarding push permission. Of course, the other direction is problematic as well. E.g. if there exists 3rd party code that is used to build the complete product, but for which not each developer has the required license to see it in source form. Again, just create a repository that only developers that have the appropriate license can see. Making the results of building it available to others is an issue for your CI/OR/etc. system, not your version control system. Then we'll have to think about moving to Fossil with our main repositories again. Key word/letter there is repositorieS. Clones repositories in fossil (and other DVCS systems) are as cheap as branches in a CVCS, and have a lot of the same properties. Many things that you'd do with a branch in a CVCS you do with a clone in a DVCS. Since merging changes between repositories is only slightly harder than merging changes between branches, this really isn't a problem. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
