2013-10-26 19:46:09 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class DiffusionSSHWorkflow extends PhabricatorSSHWorkflow {
|
|
|
|
|
|
|
|
private $args;
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
private $repository;
|
|
|
|
private $hasWriteAccess;
|
2015-01-28 23:41:24 +01:00
|
|
|
private $proxyURI;
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
|
|
|
|
public function getRepository() {
|
2013-11-11 21:19:06 +01:00
|
|
|
if (!$this->repository) {
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
throw new Exception(pht('Repository is not available yet!'));
|
2013-11-11 21:19:06 +01:00
|
|
|
}
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
return $this->repository;
|
|
|
|
}
|
2013-10-26 19:46:09 +02:00
|
|
|
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
private function setRepository(PhabricatorRepository $repository) {
|
|
|
|
$this->repository = $repository;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-10-26 19:46:09 +02:00
|
|
|
public function getArgs() {
|
|
|
|
return $this->args;
|
2013-12-03 00:45:36 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
public function getEnvironment() {
|
2013-12-05 20:59:22 +01:00
|
|
|
$env = array(
|
|
|
|
DiffusionCommitHookEngine::ENV_USER => $this->getUser()->getUsername(),
|
|
|
|
DiffusionCommitHookEngine::ENV_REMOTE_PROTOCOL => 'ssh',
|
2013-12-03 00:45:36 +01:00
|
|
|
);
|
2013-12-05 20:59:22 +01:00
|
|
|
|
|
|
|
$ssh_client = getenv('SSH_CLIENT');
|
|
|
|
if ($ssh_client) {
|
|
|
|
// This has the format "<ip> <remote-port> <local-port>". Grab the IP.
|
|
|
|
$remote_address = head(explode(' ', $ssh_client));
|
|
|
|
$env[DiffusionCommitHookEngine::ENV_REMOTE_ADDRESS] = $remote_address;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $env;
|
2013-10-26 19:46:09 +02:00
|
|
|
}
|
|
|
|
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
/**
|
|
|
|
* Identify and load the affected repository.
|
|
|
|
*/
|
|
|
|
abstract protected function identifyRepository();
|
2013-11-11 21:19:06 +01:00
|
|
|
abstract protected function executeRepositoryOperations();
|
2013-10-26 21:18:54 +02:00
|
|
|
|
2013-10-26 19:46:09 +02:00
|
|
|
protected function writeError($message) {
|
|
|
|
$this->getErrorChannel()->write($message);
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2015-01-28 23:41:24 +01:00
|
|
|
protected function shouldProxy() {
|
|
|
|
return (bool)$this->proxyURI;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getProxyCommand() {
|
|
|
|
$uri = new PhutilURI($this->proxyURI);
|
|
|
|
|
|
|
|
$username = PhabricatorEnv::getEnvConfig('cluster.instance');
|
|
|
|
if (!strlen($username)) {
|
|
|
|
$username = PhabricatorEnv::getEnvConfig('diffusion.ssh-user');
|
|
|
|
if (!strlen($username)) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'Unable to determine the username to connect with when trying '.
|
|
|
|
'to proxy an SSH request within the Phabricator cluster.'));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$port = $uri->getPort();
|
|
|
|
$host = $uri->getDomain();
|
|
|
|
$key_path = AlmanacKeys::getKeyPath('device.key');
|
|
|
|
if (!Filesystem::pathExists($key_path)) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'Unable to proxy this SSH request within the cluster: this device '.
|
|
|
|
'is not registered and has a missing device key (expected to '.
|
|
|
|
'find key at "%s").',
|
|
|
|
$key_path));
|
|
|
|
}
|
|
|
|
|
|
|
|
$options = array();
|
|
|
|
$options[] = '-o';
|
|
|
|
$options[] = 'StrictHostKeyChecking=no';
|
|
|
|
$options[] = '-o';
|
|
|
|
$options[] = 'UserKnownHostsFile=/dev/null';
|
|
|
|
|
|
|
|
// This is suppressing "added <address> to the list of known hosts"
|
|
|
|
// messages, which are confusing and irrelevant when they arise from
|
|
|
|
// proxied requests. It might also be suppressing lots of useful errors,
|
|
|
|
// of course. Ideally, we would enforce host keys eventually.
|
|
|
|
$options[] = '-o';
|
|
|
|
$options[] = 'LogLevel=quiet';
|
|
|
|
|
|
|
|
// NOTE: We prefix the command with "@username", which the far end of the
|
|
|
|
// connection will parse in order to act as the specified user. This
|
|
|
|
// behavior is only available to cluster requests signed by a trusted
|
|
|
|
// device key.
|
|
|
|
|
|
|
|
return csprintf(
|
|
|
|
'ssh %Ls -l %s -i %s -p %s %s -- %s %Ls',
|
|
|
|
$options,
|
|
|
|
$username,
|
|
|
|
$key_path,
|
|
|
|
$port,
|
|
|
|
$host,
|
|
|
|
'@'.$this->getUser()->getUsername(),
|
|
|
|
$this->getOriginalArguments());
|
|
|
|
}
|
|
|
|
|
2013-10-26 19:46:09 +02:00
|
|
|
final public function execute(PhutilArgumentParser $args) {
|
|
|
|
$this->args = $args;
|
|
|
|
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
$repository = $this->identifyRepository();
|
|
|
|
$this->setRepository($repository);
|
|
|
|
|
2015-01-28 23:41:24 +01:00
|
|
|
$is_cluster_request = $this->getIsClusterRequest();
|
|
|
|
$uri = $repository->getAlmanacServiceURI(
|
|
|
|
$this->getUser(),
|
|
|
|
$is_cluster_request,
|
|
|
|
array(
|
|
|
|
'ssh',
|
|
|
|
));
|
|
|
|
|
|
|
|
if ($uri) {
|
|
|
|
$this->proxyURI = $uri;
|
|
|
|
}
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
|
2013-10-26 19:46:09 +02:00
|
|
|
try {
|
2013-11-11 21:19:06 +01:00
|
|
|
return $this->executeRepositoryOperations();
|
2013-10-26 19:46:09 +02:00
|
|
|
} catch (Exception $ex) {
|
|
|
|
$this->writeError(get_class($ex).': '.$ex->getMessage());
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Prepare SSH connections for proxying
Summary:
Ref T7034.
In a cluster environment, when a user connects with a VCS request over SSH (like `git pull`), the receiving server may need to proxy it to a server which can actually satisfy the request.
In order to proxy the request, we need to know which repository the user is interested in accessing.
Split the SSH workflow into two steps:
# First, identify the repository.
# Then, execute the operation.
In the future, this will allow us to put a possible "proxy the whole thing somewhere else" step in the middle, mirroring the behavior of Conduit.
This is trivially easy in `git` and `hg`. Both identify the repository on the commmand line.
This is fiendishly complex in `svn`, for the same reasons that hosting SVN was hard in the first place. Specifically:
- The client doesn't tell us what it's after.
- To get it to tell us, we have to send it a server capabilities string //first//.
- We can't just start an `svnserve` process and read the repository out after a little while, because we may need to proxy the request once we figure out the repository.
- We can't consume the client protocol frame that tells us what the client wants, because when we start the real server request it won't know what the client is after if it never receives that frame.
- On the other hand, we must consume the second copy of the server protocol frame that would be sent to the client, or they'll get two "HELLO" messages and not know what to do.
The approach here is straightforward, but the implementation is not trivial. Roughly:
- Start `svnserve`, read the "hello" frame from it.
- Kill `svnserve`.
- Send the "hello" to the client.
- Wait for the client to send us "I want repository X".
- Save the message it sent us in the "peekBuffer".
- Return "this is a request for repository X", so we can proxy it.
Then, to continue the request:
- Start the real `svnserve`.
- Read the "hello" frame from it and throw it away.
- Write the data in the "peekBuffer" to it, as though we'd just received it from the client.
- State of the world is normal again, so we can continue.
Also fixed some other issues:
- SVN could choke if `repository.default-local-path` contained extra slashes.
- PHP might emit some complaints when executing the commit hook; silence those.
Test Plan: Pushed and pulled repositories in SVN, Mercurial and Git.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7034
Differential Revision: https://secure.phabricator.com/D11541
2015-01-28 19:18:07 +01:00
|
|
|
protected function loadRepositoryWithPath($path) {
|
2013-10-26 19:46:09 +02:00
|
|
|
$viewer = $this->getUser();
|
|
|
|
|
2014-03-13 20:42:41 +01:00
|
|
|
$regex = '@^/?diffusion/(?P<callsign>[A-Z]+)(?:/|\z)@';
|
2013-10-26 19:46:09 +02:00
|
|
|
$matches = null;
|
|
|
|
if (!preg_match($regex, $path, $matches)) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'Unrecognized repository path "%s". Expected a path like '.
|
|
|
|
'"%s".',
|
|
|
|
$path,
|
2014-06-09 20:36:49 +02:00
|
|
|
'/diffusion/X/'));
|
2013-10-26 19:46:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$callsign = $matches[1];
|
|
|
|
$repository = id(new PhabricatorRepositoryQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withCallsigns(array($callsign))
|
|
|
|
->executeOne();
|
|
|
|
|
|
|
|
if (!$repository) {
|
|
|
|
throw new Exception(
|
|
|
|
pht('No repository "%s" exists!', $callsign));
|
|
|
|
}
|
|
|
|
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
switch ($repository->getServeOverSSH()) {
|
|
|
|
case PhabricatorRepository::SERVE_READONLY:
|
|
|
|
case PhabricatorRepository::SERVE_READWRITE:
|
|
|
|
// If we have read or read/write access, proceed for now. We will
|
|
|
|
// check write access when the user actually issues a write command.
|
|
|
|
break;
|
|
|
|
case PhabricatorRepository::SERVE_OFF:
|
|
|
|
default:
|
|
|
|
throw new Exception(
|
|
|
|
pht('This repository is not available over SSH.'));
|
|
|
|
}
|
|
|
|
|
|
|
|
return $repository;
|
|
|
|
}
|
|
|
|
|
2013-11-11 21:19:06 +01:00
|
|
|
protected function requireWriteAccess($protocol_command = null) {
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
if ($this->hasWriteAccess === true) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$repository = $this->getRepository();
|
|
|
|
$viewer = $this->getUser();
|
2013-10-26 19:46:09 +02:00
|
|
|
|
|
|
|
switch ($repository->getServeOverSSH()) {
|
|
|
|
case PhabricatorRepository::SERVE_READONLY:
|
2013-11-11 21:19:06 +01:00
|
|
|
if ($protocol_command !== null) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'This repository is read-only over SSH (tried to execute '.
|
|
|
|
'protocol command "%s").',
|
|
|
|
$protocol_command));
|
|
|
|
} else {
|
|
|
|
throw new Exception(
|
|
|
|
pht('This repository is read-only over SSH.'));
|
|
|
|
}
|
2013-10-26 19:46:09 +02:00
|
|
|
break;
|
|
|
|
case PhabricatorRepository::SERVE_READWRITE:
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
$can_push = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$repository,
|
2014-07-25 00:20:39 +02:00
|
|
|
DiffusionPushCapability::CAPABILITY);
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
if (!$can_push) {
|
|
|
|
throw new Exception(
|
|
|
|
pht('You do not have permission to push to this repository.'));
|
2013-10-26 19:46:09 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case PhabricatorRepository::SERVE_OFF:
|
|
|
|
default:
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
// This shouldn't be reachable because we don't get this far if the
|
|
|
|
// repository isn't enabled, but kick them out anyway.
|
2013-10-26 19:46:09 +02:00
|
|
|
throw new Exception(
|
|
|
|
pht('This repository is not available over SSH.'));
|
|
|
|
}
|
|
|
|
|
Generalize SSH passthru for repository hosting
Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.
For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.
The way this will work is:
- The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
- The `willWriteCallback` will look at those messages and determine if they're reads or writes.
- If they're writes, it will check for write permission.
- If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.
Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).
Reviewers: btrahan
Reviewed By: btrahan
CC: hach-que, asherkin, aran
Maniphest Tasks: T2230
Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
|
|
|
$this->hasWriteAccess = true;
|
|
|
|
return $this->hasWriteAccess;
|
2013-10-26 19:46:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|