Can we isolate a subversion user using the mod_authz authentication such that they will only be authenticated to a single subversion repository? Right now we are hosting multiple repositories via apache, and our access_file is global across all repositories. This means if we use the *=r option, then all users will have read access. We would like to introduce a user into that environment so they will only have access to a single repo, and they will not be included in other repository access via the *=r option. Is this type of configuration available?
Thanks,
Suresh
You can use the NOT modifier on global scope of the authz file:
[/]
*=
~single_repo_user=r
[single_repo:/]
*=
single_repo_user=r
This reads:
for all repositories, nobody has any permission, except he is not user named single_repo_user, than user has read permission
for repository "single_repo" nobody has access except single_repo_user who has read access
So only single_user_repo has no permission. everybody else has read permission.
You can of course just delete the user name out of the htpasswd file..
See more infos here:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz
Related
TLDR -
I want users of my employer's organization who install my CLI tool to be able to use it to run commands that use the GitHub rest api that require permissions the user doesn't personally have, while restricting the user from using the CLI tool to perform unintended actions with the elevated permissions needed by the CLI tool. Is there a way to create a CLI tool that 1. uses permissions the users of the CLI tool don't have while at the same time 2. prevents those users from using the CLI tool's elevated permissions to perform unintended actions?
Extended -
I'm building a CLI tool for my employer's organization so that the organization members can automatically create a new branch and simultaneously add branch protection and create a PR. As far as I know, updating branch protection with the GitHub API requires admin access. However, not all of the users who use this CLI tool will personally have those permissions for their user account. But a user in the organization should still be able to use the CLI tool (which uses permissions the user potentially doesn't have).
I thought about using a personal access token so that the users aren't using a single set of centralized credentials (github app creds), but then the CLI tool would have access to at least one of the user's personal repositories and potentially wouldn't have the required permissions required by the CLI tool.
So is there a way to build a tool as a package that can be installed on a users machine that...
has permissions that the user of the tool potentially doesn't have and
prevents the user from doing anything unintended. e.g. the tool (which has admin permissions) can add branch protection rules, but the user shouldn't be able to use the tool's elevated permissions for anything else - e.g. getting the interaction limits for an organization
prevents the user from using the tool in any organization repo they don't have access to.
Ok, that's the gist of it, but I will go into more detail in case that helps.
So currently I'm using a GitHub app and giving it the required permissions (e.g. admin read/write for branch protection rules). I'm using octokit to authenticate to the GitHub API with the GitHub App. To do this, I'm passing in the app id, private key, and the installation id.
package structure
- .env
- authenticate_and_do_stuff.ts
authenticate_and_do_stuff.ts
// authenticate with GitHub app creds
// see https://github.com/octokit/octokit.js#authentication
const octokit = new Octokit({
authStrategy: createAppAuth,
auth: {
appId: process.env.GITHUB_APP_APP_ID,
privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
installationId: process.env.GITHUB_APP_INSTALLATION_ID,
},
});
// create branch, add branch protection, etc.
octokit.rest.do stuff ...
This isn't ideal because then the user who installs the package needs those environment variables to be authenticated. And once they have those creds, they would be able to use them to do other things they potentially don't have permissions for (e.g. with the admin read/write permission the GitHub app has permissions for). So my thought is to have the user provide the authentication credentials that aren't the Github app credentials. This way, each user is using different credentials they provide. As for the reasons stated above, personal access tokens cannot be used. So the ideal situation is as follows -
A user installs the package - npm i my-github-cli-tool.
- node_modules
|
--- my-github-cli-tool
|
--- authenticate_and_do_stuff.ts
|
- some_custom_app_file.ts
- .env.cli_tool
They generate credentials and put them into a custom env file e.g. .env.cli_tool.
They use the CLI tool to create a new branch in an organization repo they have access to, create the branch protection rules (with the admin read/write access that the user doesn't have, but the credentials in step 2 has).
If the user tries to alter the cli tool or use the credentials in step 2 to use it to access repos they don't have access to or perform other actions with the admin read/write permissions, they shouldn't be able to.
If I stick with using the GitHub app, the source code on the user's machine has to get the credentials somehow. And those credentials need to have elevated permissions that the user might not have. So if these credentials are exposed to the source code on the user's machine, doesn't that mean the user can just grab those credentials and use them for nefarious purposes?
I need to restrict permissions for certain branches across 50 repos for specific user groups in azure repos. This is to say, a particular group of users cannot force push to the master branch but can other branches.
This is easy enough to do in the interface, but requires going to 50+ repos and manually performing this task. I've been reading through the Azure repos API documentation and I'm struggling to see how I go about setting this?
As explained in the blog post https://jessehouwing.net/azure-devops-git-setting-default-repository-permissions/:
tfssecurity /a+ "Git Repositories" repoV2/<Team Project GUID>/<repository guid>/refs^heads^<branch name>/ "ForcePush" <memberIdentity> DENY /collection:https://dev.azure.com/{organization}
The repository guids can be found out via REST API, where GitRepository.id contains the guid:
https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-5.1#examples
See https://learn.microsoft.com/en-us/azure/devops/server/command-line/tfssecurity-cmd?view=azure-devops for more information about how to specifiy member identity.
You can use below rest api to set branch permission fors for group.
POST https://dev.azure.com/{orgname}/{projectid}/_api/_security/ManagePermissions?__v=5
Here is a sample of request body.
{"updatePackage":
"{\"IsRemovingIdentity\":false,
\"TeamFoundationId\":\"{teamfoundationId}}\",
\"DescriptorIdentityType\":\"Microsoft.TeamFoundation.Identity\",
\"DescriptorIdentifier\":\"{DescriptorIdentifier}}\",
\"PermissionSetId\":\"2e9eb7ed-3c0a-47d4-87c1-0ffdd275fd87\",
\"PermissionSetToken\":\"repoV2/{projectId}}/{repoId}}/refs^heads^{branchname}}/\",
\"RefreshIdentities\":false,
\"Updates\":
[{\"PermissionId\":1,\"PermissionBit\":32768,\"NamespaceId\":\"2e9eb7ed-3c0a-47d4-87c1-0ffdd275fd87\",
\"Token\":\"repoV2/{projectId}/{repoId}/refs/heads/{branchId}/\"}],
\"TokenDisplayName\":null}"}
Note
\"PermissionId\":1, means set the permission to Allow,
\"PermissionId\":2, means set the permission to Deny,
\"PermissionId\":1, means set the permission to Not Set.
\"PermissionBit\":32768 is the Bypass policies when completing pull requests permission.
\"PermissionBit\":128 is the Bypass policies when pushing permission.
\"PermissionBit\":4 is the Contribute policies when pushing permission.
\"PermissionBit\":2048 is the Edit polices permission.
\"PermissionBit\":8 is the Fource push permission.
\"PermissionBit\":8192 is the Manage permissions.
\"PermissionBit\":4096 is the remove other's lock permission.
Addition
There are too many parameters in the request body, you can get there parameters by offical documentations. Or I recommand you to get these parameters by using Network Tool to manual cathch them.
Artifactory allows to set Watches on specific repositories to get notification when changes happen.
When you define an internal user, this works properly.
For LDAP Users, there is no option to set a watch on a repository.
Are special settings needed to enable this feature for LDAP Users or is it imposible without any workarounds?
Thanks a lot!
The issue you are describing is not related to the LDAP users but due to one of the below options:
You are not creating the LDAP users locally on Artifactory, meaning that you are validating the user vs the LDAP server on the fly and not creating the user on Artifactory. If this is the case then the reason for you not to be able to set a watcher is that from Artifactory perspective it doesn't have a user with details (email as an example).
If #1 is not the case and you do create the LDAP users (automatically or not ) in Artifactory then check if those users have email defined upon creation in Artifactory.
I am able to authenticate radius users using radius server+pam+ssh with creating local user with blank password in linux.
Is it possible to authenticate radius users without creating users in local machine with blank password?
/etc/pam.d/ssh file as below
#%PAM-1.0
auth sufficient pam_radius_auth.so debug
auth sufficient pam_unix.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_unix.so
account required pam_auth_status.so
session required pam_unix.so
You can authenticate the user without creating an entry for him in /etc/passwd and /etc/shadow files. But now , the user is not associated with any shell in '/etc/passwd' , so it can be of no use.
Do you want to launch a shell after authentication or you want the user just to be authenticated?
I found two nss libraries that could help in this case:
libnss-mapuser from Cumulus Linux.
libnss-ato
The general process is that these will map unknown (but authenticated) user to a single user template. Each user will get his/her own /home folder though but both libs have in common that the user id will be the same.
These packages are mainly targeted at network devices where there is no ldap setup done. Cumulus describes the setup nicely.
I recommend reading https://serverfault.com/questions/538383/understand-pam-and-nss to understand what is happening there.
If I interact with Github over SSH using the git account, how does it know which files to let me access?
Is it possible on the server to detect which specific key in the authorized_keys file was used to authenticate a user? My understanding of SSH is that once my key is authenticated, I'm logged in as the git user and should have access to everything that user account has access to.
Update:
I figured gitosis had to be doing something similar in nature and so I checked out the source. As ephemient says, associating a command with a public key seems like the way to go. You can set it up so that the command receives the user's name as an argument and figure out permissions based on that.
Of course I do not know what github does but https://wincent.com/wiki/Git_repository_access_control explains the how.