[Monotone-devel] Security and Permissions
Hello, I believe that Monotone can be configured so that some users are not able to read or write certain parts of the source tree. But I can't figure out where this is explained. I can't find it in the docs. Could someone point me to the right place? Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Security and Permissions
Daniel Carrera writes: Hello, I believe that Monotone can be configured so that some users are not able to read or write certain parts of the source tree. But I can't figure out where this is explained. I can't find it in the docs. Could someone point me to the right place? The security model is actually quite crude as write permissions are database-wide. Read permissions can be per-branch within a database; see Network Service Revisited in the doc. To complement the security model, there is also a trust model. You can set up a per-user filter in your ~/.monotonerc that will hide all revisions you don't trust. See Trust Evaluation Hooks in the manual. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Fri, 10 Oct 2008 22:31:44 +0200 Daniel Carrera wrote: Hello, I'd like to officially request a mtn rebase command. I could try to write it in Lua (I don't know how hard that would be, but I'd try). Usage: mtn rebase revision-id Effect: Edit _MTN/revision to point to revision-id QuickieTasks wiki page (at http://wiki-monotone.levitte.org/wiki/QuickieTasks/ ) lists mtn detach and mtn attach, which do the same effect, if I have understood correctly. Is it better for the UI to have the action named as attach or rebase? The mtn rebase command would be different from git rebase, so it might confuse people. -- Tero Koskinen [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Security and Permissions
Ludovic Brenta wrote: The security model is actually quite crude as write permissions are database-wide. Read permissions can be per-branch within a database; see Network Service Revisited in the doc. To complement the security model, there is also a trust model. You can set up a per-user filter in your ~/.monotonerc that will hide all revisions you don't trust. See Trust Evaluation Hooks in the manual. Thanks. I just read Network Service Revisited but I cannot find rust Evaluation Hooks. Could you tell me where it is? So, if you wanted to have a secret branch (e.g. where core developers work on security vulnerabilities) you would use monotonerc, yes? pattern net.venge.monotone.secret allow [EMAIL PROTECTED] allow [EMAIL PROTECTED] This would work if you run a monotone server with netsync but if you run Monotone through SSH, a developer could just edit monotonerc to let himself into the secret branch. You could allow core developers to use SSH, but other developers would have to use netsync. Am I right? Thanks. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
Tero Koskinen wrote: QuickieTasks wiki page (at http://wiki-monotone.levitte.org/wiki/QuickieTasks/ ) lists mtn detach and mtn attach, which do the same effect, if I have understood correctly. Is it better for the UI to have the action named as attach or rebase? Some thoughts on that: If you are going to have two commands, I guess attach/detach is better. But I don't understand the need for detach. If you have only one command, I think rebase is better because it is consistent with other Monotone commands (base revision). You point out that it is not consistent with git, but Bruce explained that git is not consistent with anything. I've heard elsewhere that git is not internally consistent either. So I'm not sure that consistency with git should be a goal. I would worry that if Monotone tried to match git, then Monotone would become inconsistent too. As a new user, I can say that Monotone feels very consistent and that this has made it easier to learn for me. So it is worth pausing for a minute to think about this issue. Maybe there is a better command name we haven't thought of. I like this one: mtn set revision rev-id But that would conflict with the existing mtn set command. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Feature request: mtn rebase
Daniel Carrera [EMAIL PROTECTED] writes: [...] You point out that it is not consistent with git, but Bruce explained that git is not consistent with anything. I've heard elsewhere that git is not internally consistent either. So I'm not sure that consistency with git should be a goal. I agree that consistency with git shouldn't be a goal. Gratuitous inconsistency doesn't seem like a good goal, though, especially with what I'd guess is a well-recognised (if not well-understood) git command. Why not uncommit (by analogy with unrecord from darcs)? Or perhaps an option to update (more of an analogy with git's reset I suppose)? [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Feature request: mtn rebase
Bruce Stephens wrote: I agree that consistency with git shouldn't be a goal. Gratuitous inconsistency doesn't seem like a good goal, though, especially with what I'd guess is a well-recognised (if not well-understood) git command. I agree. Why not uncommit (by analogy with unrecord from darcs)? Or perhaps an option to update (more of an analogy with git's reset I suppose)? Between these two, I think uncommit is better. An option to update is more error prone than typing a different command. And update is a destructive command (it destroys uncommitted changes). We don't want to mix together a destructive and a safe command. If you choose uncommit, a couple of changes are needed: 1) The parameter to uncommit should be the revision you uncommit, rather than the revision you want to be at. In other words: mtn rebase p: = mtn uncommit h: 2) The user will expect uncommit to do more than just rebase. The user will expect the revision to be removed from the database, or something equivalent to that. So I propose that uncommit h: be equivalent to: mtn rebase p: mtn suspend h: Notice that I say suspend rather than kill_rev_locally. I think it's reasonable to default to not deleting revisions from the history. Even if that may surprise some users. In addition, kill_rev_locally was made intentionally long to draw attention to its danger, so it seems inappropriate to have a simple shortcut that people type often. All in all, I think I would be very happy with an uncommit like the one above. Cheers, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Security and Permissions
Hello, Hypothetically, how would you configure monotone so that a core set of developers can see one branch and the other developers can see all other branches? Would the following work or do I need some deny lines or something? comment Allow only core devs to see the secret branch pattern net.venge.monotone.secret allow [EMAIL PROTECTED] allow [EMAIL PROTECTED] comment Allow regular developers to see other branches pattern * allow [EMAIL PROTECTED] allow [EMAIL PROTECTED] allow [EMAIL PROTECTED] allow [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Sat, Oct 11, 2008 at 7:21 AM, Tero Koskinen [EMAIL PROTECTED] wrote: QuickieTasks wiki page (at http://wiki-monotone.levitte.org/wiki/QuickieTasks/ ) lists mtn detach and mtn attach, which do the same effect, if I have understood correctly. Is it better for the UI to have the action named as attach or rebase? The idea here is for detach to remove the _MTN directory entirely, thus detaching the workspace from monotone. Think cvs/svn export. Then the idea for attach is to recreate the _MTN directory in such a detached directory, after which you can investigate its status, etc. The mtn rebase command would be different from git rebase, so it might confuse people. Agreed. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Fri, 10 Oct 2008 23:30:47 +0200 Daniel Carrera wrote: Nathaniel Smith wrote: It would be quite easy to implement in mtn itself, though, because it has all the high-level code for handling file trees already. Just do something like (untested): Any chance that someone who already knows the sources could implement this feature? Here is one quickdirty implementation (the tests and the documentation are missing and the code is not cleaned up). NB that you probably can't implement this in a fully correct way in Lua, because you need to move any pending adds/drops/renames so that they apply to the new base revision; just changing the base_revision field won't do that. If all you have are file edits, then things may be fine; otherwise there's a chance of your workspace becoming inconsistent, and subsequent mtn commands will notice this and refuse to work. My version doesn't care about adds/drops/renames, so you can easily see how the workspace becomes inconsistent: $ mtn diff -rp:1cc93704f63b0a4afa10dff6844055c30e529e31 -r1cc93704f63b0a4afa10dff6844055c30e529e31 # # # add_file janusada/creatall.bat # content [c72a42424ce71cc3ca5e92576ac0079633f429c6] # ... $ mtn rebase p:1cc93704f63b0a4afa10dff6844055c30e529e31 mtn: expanding selection 'p:1cc93704f63b0a4afa10dff6844055c30e529e31' mtn: expanded to '2f7c6b4b9c8878f5932bc014452b664f79bd797a' mtn: Changed the base revision to '2f7c6b4b9c8878f5932bc014452b664f79bd797a' $ mtn diff # # no changes # $ mtn up mtn: updating along branch 'fi.iki.tkoskine.ahven' mtn: selected update target 1cc93704f63b0a4afa10dff6844055c30e529e31 mtn: [left] 8e5bd434d7de05ebea047c9fe07d102aff491ff1 mtn: [right] 1cc93704f63b0a4afa10dff6844055c30e529e31 mtn: warning: attach node 2147483783 blocked by unversioned path 'janusada/creatall.bat' mtn: misuse: 1 workspace conflicts $ -- Tero Koskinen [EMAIL PROTECTED] monotone-rebase.diff Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Feature request: mtn rebase
On Sat, 11 Oct 2008 21:16:30 +0300 Tero Koskinen wrote: Here is one quickdirty implementation NB that you probably can't implement this in a fully correct way in Lua, because you need to move any pending adds/drops/renames so that they apply to the new base revision My version doesn't care about adds/drops/renames, so you can easily see how the workspace becomes inconsistent: # add_file janusada/creatall.bat # content [c72a42424ce71cc3ca5e92576ac0079633f429c6] Oops, wrong example case. I misread how rebase should care about adds/drops/renames. Anyway, my version doesn't care about them at all. -- Tero Koskinen [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] db kill_rev_locally
Hello, When you run db kill_rev_locally, does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera wrote: Hello, When you run db kill_rev_locally, does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. On a related topic: I know that this does not actually delete the revision, but does it delete the *certs* associated with that revision? This is what the documentation says: It does not actually delete the revision's files or manifest from your database. If you run this command, and then run db check, it will note that you have an “unreferenced manifest”. If you wish to eliminate this data for good (and thus free up the space), you may use netsync to pull from your current database into a new database; this creates a copy of your old database, without the unreferenced data. However, having this data in your database will not cause any problems, and acts as a safety net; if you later realize that you do, after all, need to retrieve the data in id, then db check will let you see which manifest it was, and with some work you can extract id's data. Finally, what is a manifest? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sat, Oct 11, 2008 at 1:24 PM, Daniel Carrera [EMAIL PROTECTED] wrote: Hello, When you run db kill_rev_locally, does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. If I break into your machine and run kill_rev_locally on some real and important revision, then next time you run 'mtn sync' it will notice that the server has a copy of that revision and your machine does not, and will re-pull it. Nothing is lost. kill_rev_locally only *actually* loses information if the only copy of that information is in the database that the attacker has *direct* access to, and if they have direct access they can remove any record we would like to make anyway. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Nathaniel Smith wrote: No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. Yes it is, because it easily allows a DOS attack from a malicious developer or someone with a developer's credentials and there is no way to identify the attacker. Second, the fact that you can recover from a disaster does not mean that the attack did not succeed. There are three aspects to security against an attack: 1) Prevention. 2) Detection. 3) Recovery. Against this particular attack, Monotone only has recovery. Monotone has a great recovery system, but something in the way of prevention or detection would be a worthy improvement. For example: 1) Prevention: Remove or somehow restrict the db kill_rev_locally command and the db execute command. 2) Detection: Record who runs db kill_rev_locally (recording db execute is kind of pointless). Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sat, Oct 11, 2008 at 11:20:50PM +0200, Daniel Carrera wrote: Nathaniel Smith wrote: No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. Yes it is, because it easily allows a DOS attack from a malicious developer or someone with a developer's credentials and there is no way to identify the attacker. No. It doesn't require (monotone) credentials (ie, key). It is applicable only to those who have write access (at the OS level) to the developer's database. A malicious developer can only hurt himself, he can't publish something with his key that will kill revs from other users' databases. An attacker with write access to the developer's local db storage can do whatever he likes to that storage, regardless of code we might write in a mtn executable. The attacker can use sqlite directly to manipulate the database, or raw byte manipulation if he wants. Against this particular attack, Monotone only has recovery. Monotone has a great recovery system, but something in the way of prevention or detection would be a worthy improvement. For example: 1) Prevention: Remove or somehow restrict the db kill_rev_locally command and the db execute command. See above, the attack is outside the scope of this command to prevent. 2) Detection: Record who runs db kill_rev_locally (recording db execute is kind of pointless). And this record could also be removed when manipulating the database directly. The point about recovery is good, though - many other kinds of raw manipulation of the database will be detected as corruption, and not trusted without valid signatures. Destruction of information can only be addressed by replication. -- Dan. pgpNccP6x98Jm.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carosone wrote: This isn't really a security issue, though, because it only affects the database that it's run on. Yes it is, because it easily allows a DOS attack from a malicious developer or someone with a developer's credentials and there is no way to identify the attacker. No. It doesn't require (monotone) credentials (ie, key). It is applicable only to those who have write access (at the OS level) to the developer's database. So it can only happen if the developer has SSH access. Tell me if I'm wrong, but if you want developers to tunnel through SSH they can then execute Monotone commands including db execute. Right? A malicious developer can only hurt himself, he can't publish something with his key that will kill revs from other users' databases. An attacker with write access to the developer's local db storage can do whatever he likes to that storage, regardless of code we might write in a mtn executable. I understand where you are coming from. An attacker with arbitrary shell access could just run rm db.mtn. But there are ways to mitigate that risk. You could give them a custom shell that only allows running one command: mtn. You can also make db.mtn and ~/.monotonerc belong to root an run mtn with the set-UID bit like the mount command. The problem of malicious insiders is well established and there are a number of known solutions to mitigate the risk. But these solutions fall apart if a program that insiders are supposed to run is insecure. You could deny SSH access to developers, but that has other security implications that some projects may find unacceptable. Allow me to make a recommendation that I think everyone will find acceptable: Create a mechanism to disable certain commands through a config file. Disable kill_rev_locally and execute by default. This removes no functionality for users who want to run these commands locally. But an admin on a server can look to protect this file just as he protects the database file. Monotone already depends on ~/.monotone being secure for other purposes, so this does not generally impose an additional requirement on the admin. Developers who want to run these commands locally, can do so easily. Admins who want to secure their server, can do so easily. Everyone's happy. Kind regards, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: Against this particular attack, Monotone only has recovery. Monotone has a great recovery system, but something in the way of prevention or detection would be a worthy improvement. For example: 1) Prevention: Remove or somehow restrict the db kill_rev_locally command and the db execute command. 2) Detection: Record who runs db kill_rev_locally (recording db execute is kind of pointless). Monotone *cannot* have anything but recovery. If the attacker has write access to your database on the filesystem (which is necessary for thsi attack), he/she can just fire up 'sqlite' and remove as many records as desired. It doesn't matter what monotone wrote or annotated, in that case. In general, yes, audit trails are great -- but make sure your prevention and detection match the threat model you're supposing. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Monotone *cannot* have anything but recovery. If the attacker has write access to your database on the filesystem (which is necessary for thsi attack), he/she can just fire up 'sqlite' and remove as many records as desired. It doesn't matter what monotone wrote or annotated, in that case. In general, yes, audit trails are great -- but make sure your prevention and detection match the threat model you're supposing. See my last email. There are standard ways to avoid modification of the database file through anything but 'mtn'. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: db kill_rev_locally
Daniel Carrera [EMAIL PROTECTED] writes: [...] So it can only happen if the developer has SSH access. Tell me if I'm wrong, but if you want developers to tunnel through SSH they can then execute Monotone commands including db execute. Right? Indeed. So don't do that. Instead, offer a monotone server that people can push to. (That's how monotone's intended to be used. Other systems work differently---git's daemon isn't really intended for pushing to, for example; ordinarily the people who update the repository uses ssh, and often that's one person (other people send patches by email, or offer up servers for pulling from).) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sun, Oct 12, 2008 at 12:01:16AM +0200, Daniel Carrera wrote: I understand where you are coming from. An attacker with arbitrary shell access could just run rm db.mtn. But there are ways to mitigate that risk. You could give them a custom shell that only allows running one command: mtn. You can also make db.mtn and ~/.monotonerc belong to root an run mtn with the set-UID bit like the mount command. I would not recommend running Monotone setuid root! For one thing, it is not required. Monotone runs fine as a regular user. You would be far safer running Monotone setuid as some non-privledged user. (In which case what you suggest is a good idea for mediating access through the mtn binary) I am the author of Botan, which is a library used in Monotone. I could not even be sure that Botan is safe to use in a setuid program. And of course Monotone is much larger than just one library, and interacts with both the filesystem and the network. In general running a program setuid root that is not explicitly written to be setuid is very dangerous - there are a lot of ways to mess up, even if you are being careful (if you haven't seen it, Setuid Demystified explains some of the common failures - http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf) The problem of malicious insiders is well established and there are a number of known solutions to mitigate the risk. But these solutions fall apart if a program that insiders are supposed to run is insecure. I do think that Monotone's current authorization control system is far too simplistic. I liked the authentication system Shapiro designed for OpenCM. It was simple, could be very fine grained if required, and was easy to manage project access controls. A design change the Monotone designers call policy branches may or may not fix a lot of the perceived shortcomings of the current model. I know there was an implementation of policy branches going, but I don't know if it was completed. It certainly is not included in normal releases. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Jack Lloyd wrote: I would not recommend running Monotone setuid root! For one thing, it is not required. Monotone runs fine as a regular user. You would be far safer running Monotone setuid as some non-privledged user. (In which case what you suggest is a good idea for mediating access through the mtn binary) You are right. Your idea is much better. I am the author of Botan, which is a library used in Monotone. I could not even be sure that Botan is safe to use in a setuid program. It's wise to not run setUID root if you don't have to. And you've shown that Monotone doesn't have to. A secure server would make a custom user just for Monotone, similar to how Apache runs as its own user. That would be a great way to restrict access to the database and ~/.monotone. The problem of malicious insiders is well established and there are a number of known solutions to mitigate the risk. But these solutions fall apart if a program that insiders are supposed to run is insecure. I do think that Monotone's current authorization control system is far too simplistic. Perhaps. But I wanted to suggest only a small easy change in the hopes that it would be more acceptable to developers. I am writing a paper on the security of Monotone. I'm following David A. Wheeler's paper on SCM security: http://www.dwheeler.com/essays/scm-security.html You may be interested to know that Monotone seems to do very well against David's criteria except for the concern over malicious developers or attackers with stolen credentials. If Monotone had a config file where you could disallow certain commands, that would be enough to make it do impressively well against David's criteria. The only feature missing would be support for encrypted branches. But as of today, the presence of db execute is a major security gap. Especially because the only way to fix it (deny SSH access) opens a different security gap (trusted paths). If you are interested, I'd be happy to show you the paper when it's one. I expect to finish tomorrow. Best, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: In general, yes, audit trails are great -- but make sure your prevention and detection match the threat model you're supposing. See my last email. There are standard ways to avoid modification of the database file through anything but 'mtn'. Yeah, our emails crossed; I didn't realize you were trying to optimize for ssh serving of monotone databases. Serving a monotone database over ssh is not really a solution, it has a number of drawbacks (mostly stemming from the fact that monotone is really Not Very Good at sharing database access). If you have to serve through ssh, you'd be much better off starting a netsync server somewhere on a localhost port, and tunneling that port through ssh. That will take care of both concurrency and your security concerns in a much cleaner fashion. Of course, you can also build a modified monotone binary to simply not offer most of the 'db' commands. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Yeah, our emails crossed; I didn't realize you were trying to optimize for ssh serving of monotone databases. Serving a monotone database over ssh is not really a solution, it has a number of drawbacks (mostly stemming from the fact that monotone is really Not Very Good at sharing database access). It certainly has drawbacks, but AFAIK it is the only way. If you have to serve through ssh, you'd be much better off starting a netsync server somewhere on a localhost port, and tunneling that port through ssh. That will take care of both concurrency and your security concerns in a much cleaner fashion. How do you do that? I'm interested to hear more. What kind of access do you need to do this? Can you do it if you are an un-privileged user? If you can, that would be really neat. Are there any drawbacks to your solution? (e.g. what if the server reboots? can you setup a cron job to check that the server netsync server is up?). I'm writing an informal paper on Monotone security (following the one from David A. Wheeler). I would like to add a section on how to setup Monotone through SSH to get the optimal security. I would be happy to share this paper if anyone finds it interesting. Cheers, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: If you have to serve through ssh, you'd be much better off starting a netsync server somewhere on a localhost port, and tunneling that port through ssh. That will take care of both concurrency and your security concerns in a much cleaner fashion. How do you do that? I'm interested to hear more. What kind of access do you need to do this? Can you do it if you are an un-privileged user? If you can, that would be really neat. Are there any drawbacks to your solution? (e.g. what if the server reboots? can you setup a cron job to check that the server netsync server is up?). It is possible to restrict the monotone server, but restricting it would break a large number of normal applications, as well. SELinux or similar technologies might be able to effectively restrict it, but I doubt any hosting service that would allow you to install and execute a monotone binary in your hosted space would be using such technologies, or have them configured to prevent this. It is also possible to restrict ssh port forwards, and this may be more likely. I don't have any idea how common such restrictions are. I use no services which restrict port forwards. Simply start mtn serve on the hosted server as 'mtn serve localhost:4691' (or whatever port -- any port over 1024 is available to non-root users, 4691 is the default monotone port). This will start a monotone netsync server which can be connected to *only* by processes on the local machine, over loopback. Then, to connect to the server, run something like the following on your workstation: ssh -L4691:localhost:4691 server This somewhat confusing command line says Forward port 4691 (the leading 4691:) on the local host (-L) to port 4691 on the remote machine (localhost:4691). See 'man ssh' for more on -L (and its closely-related cousin, -R). If you used a server port other than 4691 for 'mtn serve', replace the *final* 4691 in the above command with the port the server is using. Having done this, on your workstation again, run: mtn sync localhost pattern If you used a port other than 4691 as the first argument to ssh -L, provide it as localhost:port in the above command. This will connect to your workstation on a port which SSH tunnels through its own connection to the remote host and connects to the remote monotone server. As far as drawbacks, they are what you would expect; you have to have the SSH tunnel running to access monotone, the encrypted stream is overhead, etc. However, you pay all those penalties to use monotone via SSH in any fashion. Keeping the server running is the same as keeping any server running. There are various scripts out there which will help with that task. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Simply start mtn serve on the hosted server as 'mtn serve localhost:4691' (or whatever port -- any port over 1024 is available to non-root users, 4691 is the default monotone port). This will start a monotone netsync server which can be connected to *only* by processes on the local machine, over loopback. Then, to connect to the server, run something like the following on your workstation: ssh -L4691:localhost:4691 server This somewhat confusing command line says Forward port 4691 (the leading 4691:) on the local host (-L) to port 4691 on the remote machine (localhost:4691). See 'man ssh' for more on -L (and its closely-related cousin, -R). If you used a server port other than 4691 for 'mtn serve', replace the *final* 4691 in the above command with the port the server is using. And allowing this does not require giving developers the ability to SSH into the server through the terminal? How do you do this? Having done this, on your workstation again, run: mtn sync localhost pattern If you used a port other than 4691 as the first argument to ssh -L, provide it as localhost:port in the above command. This will connect to your workstation on a port which SSH tunnels through its own connection to the remote host and connects to the remote monotone server. Interesting. I'm still confuse about whether this requires giving developers SSH login access or not. How can you tunnel through SSH without a login? As far as drawbacks, they are what you would expect; you have to have the SSH tunnel running to access monotone, the encrypted stream is overhead, etc. However, you pay all those penalties to use monotone via SSH in any fashion. Yeah, that's fine. Like you said, it's no worse than the standard SSH solution. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] new include/exclude commands?
I had an idea the other day, where I was continually having to provide a bunch of --exclude optons in a workspace with some (intentionally) missing files, that it might be useful to be able to specify a set of includes or excludes that persist across several commands. This would avoid the need to repeatedly specify the set of paths to include or exclude. It turns out to be very simple to implement and I have a the basics working so I thought I'd check and see if people would generally find this good, bad or ugly. The basic idea is: $ mtn include aaa bbb ccc $ mtn exclude ddd eee fff $ mtn status Including: aaa bbb ccc Excluding: ddd eee fff Current branch: ... Changes against parent ... This is exactly equivalent to saying 'mtn status aaa bbb ccc --exclude ddd --exclude eee --exclude fff' with current monotone. At the moment, saying 'mtn include' or 'mtn exclude' with no arguments clears the associated list of paths. Repeated 'mtn include' or 'mtn exclude' commands with paths simply append more paths to the include or exclude list. With a bit more work this could lead quite easily to the idea of a partial checkout, where lots of things are missing, but listed as excluded. Again, whether this is generally useful or not is probably debatable. Comments? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: This requires SSH access to the server in exactly the same manner that running a remote monotone process does. You do not have to give the user access to a general purpose shell; a binary which simply does nothing forever, or sleeps for a period of time and then exits is sufficient. The latter is a decent solution if resources are a concern, because the SSH tunnel will prop open the SSH connection until it is finished, at which point the entire connection will close if the login shell has exited. In short, they have only to be able to authenticate, not *do* anything on the remote side. All developers can be given access to the same account on the server, with ssh keys granting access only to a dummy shell, or whatever normal precautions you would take. I see now. So the idea is to give them a custom shell that does nothing, but otherwise login through SSH as usual. I get it (I think). Thanks, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Thu, Oct 9, 2008 at 7:43 PM, Jack Lloyd [EMAIL PROTECTED] wrote: On Thu, Oct 09, 2008 at 07:39:51PM -0600, Derek Scherger wrote: Looking at the current checks for botan versions it seems that if I happened to have 1.8.12 we would let it in because we check for major ==1 and patch between 8 and 17. Would using the version macros that botan defines be a better way to check things? +1 I've made this change and also moved sqlite to the Attic which went much more smoothly than I was expecting since it involved upgrading from 3.4.2 to 3.5.9. One test fails with this later change, fail_cleanly_on_unreadable_db, which I assume is an actual change in sqlite behaviour but I'm not certain of this. I'm now looking at idna (libidn) which ought to be easy but isn't because of some changes that were made at the 2007 summit iirc. Lapo, do you recall the best effort stuff that got added to idna/toutf8.c? This is not in idna 1.5 but I'm wondering if maybe idna 1.5 might just do the right thing? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
