Question regards Gerrit 2.14
Goal
I want to have projects visible only to Registered Users, and also I would wish that 'owner' of project can set it's visibility, share, hide etc without admin rights, or involving admin to set those rights for him/her per project. For example I want to have projects A, B, C, D, E with B, C owned by p1, and C shared between p1, p2. So user p1 would see B, C, and user p2 would see C.
What I've checked
I believe that there are 3 ways of achieving something described above:
user has admin rights - can set parent of project other than All-projects: I don't want that
admin can set per project ACL for user/group: I don't want that
user becomes Project Owner of projects s/he created
By default "Create Project" is not granted for Registered users and "READ for refs/*"
I have tried
Setting permissions in All-Projects.git that all project inherit
Create Group
Registered Users
Create Project
Registered Users
Reference: refs/*
Allow Administrators
Allow Project Owners
Deny Anonymous Users
/* IF I add ALLOW Registered Users here -> see bottom of question */
and all remaining permissions unchanged, I expected to be able, as registered user:
Be sure that anonymous (not registered/logged on) users cannot view projects
Create project using both GUI and SSH
Be assigned as Project Owner to that project - have full control over this single project
Result
Unfortunately, registered user can create project (if user does not select previously prepared parent All-public-projects - which grants multiple other permissions - default All-projects is assigned as parent) BUT user, who is supposed to be Project Owner cannot access this project.
Ideas what is wrong
I'm aware that Registered Users are members of Anonymous Users group as well, but documentation states
Inherited access rights can be overwritten unless they are defined as BLOCK rule. BLOCK rules are used to limit the possibilities of the project owners on the inheriting projects.
Changing the parent of a project is only allowed for Gerrit administrators. This means you need to contact the administrator of your Gerrit server if you want to reparent your project.
and also
[READ] This category has a special behavior, where the per-project ACL is evaluated before the global all projects ACL. If the per-project ACL has granted Read with 'DENY', and does not otherwise grant Read with 'ALLOW', then a Read in the all projects ACL is ignored. This behavior is useful to hide a handful of projects on an otherwise public server.
For an open source, public Gerrit installation it is common to grant Read to Anonymous Users in the All-Projects ACL, enabling casual browsing of any project’s changes, as well as fetching any project’s repository over SSH or HTTP. New projects can be temporarily hidden from public view by granting Read with 'DENY' to Anonymous Users and granting Read to the project owner’s group within the per-project ACL.
Now since I do not want to set permissions per project basis, am I correct to think that reason for this to fail is
For the All-Projects root project any Owner access right on 'refs/*' is ignored since this permission would allow users to edit the global capabilities, which is the same as being able to administrate the Gerrit server (e.g. the user could assign the Administrate Server capability to the own account).
Questions
If my reasoning is correct, how do I achieve my goal?
Also, granting READ refs/* to Registered User makes project to be accessible, but also all others too. How would I then be able to hide some projects from other Registered users? Or if that is not possible - how do I configure permissions in order to prevent other registered users to commit, and possibly even clone other projects?
Additional question.
How do I quickly see who is set as project's Project Owner?
I'm glad to see not beeing the only one with such a requirement. For me everything would work just fine if the user who creates a project via Gerrit's Web UI would be automatically the project owner (only if the user is not and Admin User). However, as you know the current Web UI does neither pass this information to the Gerrit backend nor does it allow to assign project owners when creating a new project. I see the following options:
Open a feature request for the Gerrit dev team hoping they will consider the idea
Use the create-project REST API and pass the project owner(s) for creating projects, i.e. using an own app
Use the create project CLI and pass the project owner(s) for creating projects
Implement an own Gerrit Plugin - see 2. Plugin Development which would make the current user creating a new project a project owner
For me only option 1 or 4 is viable because the other mean way too much overhead. I'm thinking about writing such a plugin, and I would make it opensource... About 2 months ago I was hoping there's aready something available I could use, but I couldn't find anything.
To your second question: I typically us the Web UI for this by going to the project's Access tab and then checking the who has the permission "Owner" for the branch refs/*.
Related
We have some old ADO/VSTS projects that we want to archive and make read only. Each project has work items, builds, git repos, etc...
at the moment the only methods I have found are painful.
Remove all groups except read only group and add users in there. this is too painful and long, we have over 300 projects to make read only
Create a new group and then add in other groups (e.g. proj admins, contributors etc..) and then add this group to the top level area/git repo path and set all to DENY. *
I tried this with git repos and There is some issues with this as some
permissions are not inherited down to individual users who created the
git repo and they are still able to checkin.
Here you can see I created a READONLY group and set everything to DENY except Read permissions. (The members of this group are the default groups e.g. contributors, build admins, proj admins)
However, I had a repo created by a test user BEFORE i created the readonly group and it seems that user still has permissions to that repo
ok ok I understand that if the permissions are set at the lower level, then they won't be inherited down from the top level parent. I could create a script that checks the users of every git repo and sets their check-in permissions to deny but that is painful and i would prefer not to do that. Likewise, some projects have over 300 git repos.
FYI I want to make the whole project read only not just git repos.
Azure DevOps now have a feature called: "Disable Repository".
Disable access to to the repository (including builds, pull requests,
etc) but keep the repository discoverable with a warning.
It means your repo will not allow commits, even builds and pipelines cannot use it. Just go to your Devops "Project Settings". Scroll down to "Repositories" menu and select which Repo do you want to disable.
Yeah, you've found one of the nasty features of the Azure DevOps permission model. More specific ACLs trump less specific ACLs. Even for DENY rules.
When there is an explicit ALLOW rule on a more specific ACL, it will override the DENY on a less specific ACL.
Specificity for git is based on:
Server (TFS only)
Organization / Project Collection
Project
Default repo settings
Specific repo settings
Branch folder settings (only settable through API)
Specific branch settings
Similar hierarchies exist for other securables.
There is no easy way to strip these all, apart from scripting the action.
The Azure CLI has a devops extension which will allow you to script out what you want and can output JSON to make it easier to script.
You can use az devops security permission list to list all permissions defined for a identity (group or user) and az devops security permission reset or az devops security permission update to unset or override the given permission.
Other probably needed calls:
az devops security group list
az devops user list
az devops security group membership *
You can use the Azure DevOps disable repository option, which has the disadvantage that the repo is not showing up in the list of repos under the project anymore. This might not be desired if the code should still be readable for reference purposes.
The other method explained in one of the answers is to manually remove any write permissions using the repository settings UI. If you have a lot of access control lists on your repos or even need to do this on multiple repos, the manual approach can become time consuming. Therefore I wrote a script to automate this: https://github.com/ckadluba/RemoveAzureGitRepoWritePermissions.
It basically works like this.
.\Remove-AzureGitRepoWritePermissions.ps1 -OrgName "myorganisation" -ProjectName "MyProject" -RepoName "MyRepo"
It sets an explicit deny for the permissions: GenericContribute, ForcePush, CreateBranch, CreateTag, ManageNote, PolicyExempt, PullRequestContribute
and PullRequestBypassPolicy.
Have a business requirement to prevent development users from being able to access production and integration MFP environments; However, they can retain full access to the test environment.
Currently have the following Active Directory security groups configured for the production environment:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
mfpanalytics_administrator
mfpanalytics_infrastructure
mfpanalytics_support
mfpanalytics_developer
mfpanalytics_business
mfpappcenteradmin
mfpappcenteruser
Within the server.xml file there is an LDAP connection and then a section defining security roles. These AD group names are reflected in the security role section. To fulfill the requirement above, one may presumably creates new active directory security groups similar to the ones listed above (something like mfpadmin-test, mfpadmin-int), add development users to these newly created test groups, e.g., mc-admin-test, remove these same users from the groups defined for the production environment, e.g., mfpadmin, and update the appropriate server.xml file.
Is there anything inside of the specific applications (Admin, Analytics, AppCenter) that one needs to do to further restrict access?
Is there anything needed to be done with the war file?
Is there anything inside of the specific applications (Admin, Analytics, AppCenter) that one needs to do to further restrict access?
(A) No just defining the right security roles should be sufficient
Is there anything needed to be done with the war file?
(A) No , nothing to do with the war file.
mfpadmin,mfpdeployer,mfpmonitor, and mfpoperator are the default security roles defined by Mobilefirst. The same security roles will need to be defined for your test and integration environments. These security roles can in-turn be grouped to the right groups i.e
mfpadmin-test, mfpadmin-in etc.
We have a Windows SBS 2008 domain controller (the only one in our domain) and I'm trying to create a new Group Policy Object to handle printers. Every time I attempt to create a new GPO, either in the Group Policy folder directly or the linked in one of the organizational folders I receive the following message - "This security ID may not be assigned as the owner of this object." I've been looking around but I haven't found anything that works. Most results for this search indicate that people are having trouble with Folder Redirection policies. We have Folder Redirection enabled, but every workstation in the domain is running Windows 7 Professional, and no one is having trouble with the redirection policy. I've double-checked the sysvol directory and both SYSTEM and Administrators have the appropriate rights. I've added the sysadmin account to the Group Policy Creator Owners group (which again, has rights to sysvol) but still nothing. I've been at this all day and I'm coming up completely empty. There's nothing in the Event View logs, and I even created another administrative level user or simply copy/pasting an existing GPO. Same message everytime. This only started happening this week. Does anyone have any idea? I'm starting to get desperate.
Looks like I managed to solve it. Probably not ideal, but I'll share in case anyone else has a similar issue. Looks like the permissions were not correct as I had assumed. I went through again and granted Full Control to the Group Policy Creator Owners group on the following three folders: C:\Windows\sysvol\sysvol, C:\Windows\sysvol\sysvol\ourDomain.local, and C:\Windows\sysvol\sysvol\ourDomain.local\Policies. The last one, I set the rights to extend to subfiles and folders. After a quick logout to reset the permissions, I was able to create a new policy object.
I just encountered this issue. Google finds solutions (such as here) suggesting you verify you or your security group (domain admins, builtin\administrators) have Group Policy permissions in the Default Domain Controllers Policy at Computer Config > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Restore files and directories.
In my case, I also had to confirm the same permissions in my Default Domain Policy. I'm not sure how they changed, but after adding the group and forcing a Group Policy refresh (gpupdate /force), the problem was resolved.
I have various projects being built and tested periodically on a Hudson server, but I don't want every employee in the company to see published artifacts for every project.
Project-based matrix security seemed at first the key, but after many tests I find that granting overall read permissions is mandatory if you want users to be able to read anything in the hudson server.
So, in the end read permissions are binary: either you grant global read permission or you block everything, am I right?
Haven't it tested with the newest release, but I use the matrix setup. I gave Anonymous the overall read. This way they can see the login screen when they type {{http://servername:port/}} but does not give them access to the jobs. In the jobs themselves I configured the users that should actually see the job. Works like a charm.
UPDATE:
Meanwhile I found out that you can use authenticated instead of Anonymous. This enabled access to Hudson/Jenkins through the links in the Build failed messages. Now everyone gets the logon dialog and after signing in, they are right away at the job run of interest.
After trying to do something similar to you with Hudson's authorization settings, I came to the same conclusion you did.
When an ASP.NET application is running under IIS6.0 in Windows 2003 Server with impersonation, what user account is relevant for deciding file read/write/execute access privileges? I have two scenarios where I am trying to understand what access to grant/revoke. I thought the most relevant user is probably the identity specified in the Application Pool, but that doesn't seem to be the whole story.
The first issue concerns executing a local batch file via System.Diagnostics.Process.Start()--I can't do so when the AppPool is set to IWAM_WIN2K3WEB user, but it works fine if it is set to the Network Service identity. I of course made sure that the IWAM user has execute rights on the file.
The second involves writing to a file on the local hard drive--I'd like to be able to prevent doing so via the access control list via folder properties, but even when I set up all users in the folder as "read" (no users/groups with "write" at all), our ASP.NET still writes out the file no problem. How can it if it doesn't have write access?
Google search turns up bits and pieces but never the whole story.
what user account is relevant for [..] file read/write/execute access
As a rule: Always the user account the application/page runs under.
The IWAM account is pretty limited. I don't think it has permissions to start an external process. File access rights are irrelevant at this point.
If a user account (Network Service in your case) owns a file (i.e. has created it), it can do anything to this file, even if not explicitly allowed. Check who owns your file.
Process Monitor from Microsoft is a great tool to track down subtleties like this one.
A bit more searching reveals that the IWAM user isn't that well documented and we should stick with NETWORK SERVICE or a manually-supplied identity if we want to specify permissions for that user.