Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factorized the code for allow_access and allow_publish #101

Closed
wants to merge 9 commits into from

Conversation

Telokis
Copy link

@Telokis Telokis commented Nov 19, 2019

Closes #100

This PR aims to fix the security issues the current allow_access implementation has.
Anybody can access any package as long as he is authenticated.
Instead of just fixing this issue, the new branch completely merges the behavior of allow_access and allow_publish by introducing a generic allow_action function that is used by both of them.
The new behavior allows users to specify $authenticated and $all/$anonymous for both publish and access.
It also introduces a new meta-group: $owned-group (This name could change before the release). This meta-group represents a permission where the user can only perform the action on a package where he has publishLevel permission in Gitlab. This is the curent behavior for publish.

- allow_access
- allow_publish
@Telokis
Copy link
Author

Telokis commented Dec 3, 2019

I updated the tests and the README (I took the liberty to incorporate and adapt the changes suggested by @slhck in #104 ).

Copy link
Owner

@bufferoverflow bufferoverflow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, I left a few comments.

@@ -52,13 +52,13 @@ packages:
'@*/*':
# scoped packages
access: $all
publish: $authenticated
publish: $owned-group
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should e.g. be $maintainer as described here https://github.com/bufferoverflow/verdaccio-gitlab#configuration-options.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about doing it this way but the issue is that I would need to retrieve all user's projets/groups. The current way is to retrieve only the groups/projets where the user is at least auth.gitlab.publish meaning that I would have to change that as well.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, when working on this PR, I decided to use $owned-group as a way to represent the current behavior that the plugin is using for publish authorization.
The naming may not be ideal (though I have nothing better in mind, yet) but it's there for the user to have a way to say "Only do this action if you have at least auth.gitlab.publish permission on the associated group/project".

I think adding support for $maintainer, $owner, ... beyond the auth.gitlab.publish should be another PR with a discussion regarding the design itself.

I'm not sure you remember my other issue but I made this PR because I plan to do #99 right after it's merged.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bufferoverflow What should I do regarding this comment?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$maintainer is the current default as figured out here, so we do not need $owned-group

Copy link
Owner

@bufferoverflow bufferoverflow Jan 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/bufferoverflow/verdaccio-gitlab/blob/master/src/authcache.ts#L50 does not have the access level, so if we add functionality for different access levels, people should be able to define the level of their choice for access and publish.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for now they will both use the publishLevel value without distinction.
The proper way would be to be able to specify $maintainer, $owner and so on for both publish and access but this requires much more work. (as mentioned here: #101 (comment))

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have any other feedback or is this PR ok as-is?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as said, if we add functionality for different access levels, people should be able to define the level of their choice for access and publish.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but this is not the goal of this PR. Its only goal is to increase security.

condition at all.
- `$authenticated`: Any successfully authenticated user can perform the action
on the packages.
- `$owned-group`: A user can perform the action on a package if
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to take care on the access level and I think there is no need for $owned-group as we have access level for this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my answer above, I would need to alter the way the extension retrieve the user's data.

package.json Outdated
@@ -6,7 +6,7 @@
},
"scripts": {
"type-check": "tsc --noEmit",
"commitmsg": "commitlint -e $GIT_PARAMS",
"commitmsg": "commitlint -q -e $GIT_PARAMS",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept getting a formatted.join when executing commitlint commands. Absolutely no idea why and I didn't feel like investigating the library.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I agree that I shouldn't quiet it. It totally disables the error output which makes fixinx lint errors annoying.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding this, I also noticed a deprecation warning:

$ yarn run commitmsg
yarn run v1.19.0
$ commitlint -e $GIT_PARAMS
Using environment variable syntax ($GIT_PARAMS) in -e |--edit is deprecated. Use '{-E|--env} HUSKY_GIT_PARAMS instead'
C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:119
        throw err;
        ^

Error: Received $GIT_PARAMS as value for -e | --edit, but GIT_PARAMS or HUSKY_GIT_PARAMS are not available globally.
    at getEditValue (C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:307:9)
    at normalizeFlags (C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:268:15)
    at C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:126:11
    at new Promise (<anonymous>)
    at main (C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:123:9)
    at Object.<anonymous> (C:\Users\Telokis\Documents\git\verdaccio-gitlab\node_modules\@commitlint\cli\lib\cli.js:115:1)
    at Module._compile (internal/modules/cjs/loader.js:759:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:770:10)
    at Module.load (internal/modules/cjs/loader.js:628:32)
    at Function.Module._load (internal/modules/cjs/loader.js:555:12)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I can easily fix it by removing $GIT_PARAMS from the arguments.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed this fix and reverted the -q

@@ -37,6 +37,7 @@ const BUILTIN_ACCESS_LEVEL_ANONYMOUS = ['$anonymous', '$all'];

// Level to apply on 'allow_access' calls when a package definition does not define one
const DEFAULT_ALLOW_ACCESS_LEVEL = ['$all'];
const DEFAULT_ALLOW_PUBLISH_LEVEL = ['$owned-group'];
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be $owner

Copy link
Author

@Telokis Telokis Dec 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were to do it the way you suggest, I think the default value should be $maintainer since it currently is the default value in the code.

this.publishLevel = '$maintainer';

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, this makes sense

@Telokis
Copy link
Author

Telokis commented Dec 16, 2019

By the way, I didn't mention it but I think this should be a major release, it will break all existing configurations relying on $authenticated.

@bufferoverflow
Copy link
Owner

as said, if we add functionality for different access levels, people should be able to define the level of their choice for access and publish.

#101 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Security concerns
2 participants