Nexus 3 installation with both public and private repositories: hiding existence of private ones

643 views
Skip to first unread message

Keith Hughes

unread,
Dec 13, 2016, 5:38:24 PM12/13/16
to Nexus Users
OK, I am glad I fully experimented with this before asking my question as I now have what seem to be the full set of details.

So I have a Nexus 3.1 installation with a set of repositories, some I want to be public, some I want to be private.

I created a role of my own called Site Anonymous that I put in the roles that I want available for the anonymous user. This includes one set of public snapshot and release directories.

When I go to the site anonymously I can see the existence of my private repositories, they show up in the web UI. When I attempt to drill down into them or search them, I only see them as empty, which is good, because I want the contents to be private. But in my ideal world, the existence of the repositories would also be hidden for an anonymous user.

Is it somehow possible in 3.1 to hide the existence of repositories for anonymous users? Or is this not a feature that anyone else would care about?

Thanks!
-Keith

Fraser Goffin

unread,
Dec 14, 2016, 3:52:26 AM12/14/16
to Keith Hughes, Nexus Users
I would be interested in that feature. Clearly as part of any security
model the visible attack surface provides useful clues to anyone
looking to breach that security, you wouldn't publish your complete
network topology to anyone who happened by.

OTOH, there can be a use case where you want to make groups of users
aware that resources exist even if they can't (at some point in time)
access them yet. This comes up when you are trying to reduce
duplication of APIs or other assets simply because some people didn't
know that asset is already maintained as a shared resource.

So maybe there is at least two roles here, one which is genuinely
anonymous, and another which is un-authenticated internal ?

No idea if that helps or if Nexus 3.x can be configured to support it,
but, maybe it serves as a potential requirement which the guys at
Sonatype can comment about ?

Regards

Fraser.
> --
> You received this message because you are subscribed to the Google Groups
> "Nexus Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nexus-users...@glists.sonatype.com.
> To post to this group, send email to nexus...@glists.sonatype.com.
> To view this discussion on the web visit
> https://groups.google.com/a/glists.sonatype.com/d/msgid/nexus-users/9c96a159-c509-4619-83d5-e1afe6a65cf9%40glists.sonatype.com.
> For more options, visit
> https://groups.google.com/a/glists.sonatype.com/d/optout.
>

Keith Hughes

unread,
Dec 14, 2016, 8:46:45 AM12/14/16
to Fraser Goffin, Nexus Users
I can see use cases for both. But definitely my usecase is to have some invisible ones on the same Nexus instance rather than having to run 2 instances of Nexus.

Not entirely sure what the correct permissions should be. nx-view-maven2-foo-visible?

It would also be good to have some explanations of the actions in the permissions in the docs. I presume those actions are comprised of groups of the fundamental permissions, knowing what each one adds would be good. The documentation is a little sparse on the permissions, for example, the admin vs view permissions, etc.

I should see if some of the other OSS repositories have this visible/invisible. I would still like to stick with Nexus, I have used it in the past, but I may decide my usecase is compelling enough. to look elsewhere.


Brian Fox

unread,
Dec 14, 2016, 9:43:16 AM12/14/16
to Keith Hughes, Fraser Goffin, Nexus Users
Hi all, 

Currently as implemented, Nexus 3 is not applying the read permissions as a filter to what can be seen in the UI. That's a pending item to be resolved.

Our current plan is to simplify things a bit from where Nexus 2 was originally. What we had originally provided for was the ability to read from a repository (effectively through a group) but not to be able to see it (hence the separate view permission). We've done away with the view priv for now on the hopes that it's not required because of some other things.

So the question that will help sort this out is:

1) are you primarily concerned that people can discover repos they shouldn't have access to, nor know about and thus it's "expanding the attack surface)

or

2) are you trying to have people read contents if they know the url, but otherwise not be able to see it in the UI? If so, more detail on why would really help here.

--Brian

To view this discussion on the web visit https://groups.google.com/a/glists.sonatype.com/d/msgid/nexus-users/CALJKi6UwM248M3O1k%3DjPHpJxbYx0jXe%2ByMetseVdvRx5AdoeTg%40mail.gmail.com.

Keith Hughes

unread,
Dec 14, 2016, 10:14:31 AM12/14/16
to Brian Fox, Fraser Goffin, Nexus Users
Hi Brian,

For me I am more interested in 1. Part of it is to do with expanding the attack service, as Fraser put it, if people know what is there it is easier to encourage probing there, but also to not leak information about the organization outside of the organization. While one can argue that knowing I have a private PyPi repo doesn't say much, it is talking about things that are going on inside the company that seems best left private.

From a UX perspective, it is also a bit odd to be able to see a repo that always looks empty for many folks. Is it empty, or is it just private?

As for 2, I would imagine having the URL should fail for anonymous access if the UI would never show you the thing in the first place. That seems like a security breach waiting to happen.

You say the read permission as a filter for view in the UI is a pending issue. Any idea when it will be completed?

Best,
-Keith

Brian Fox

unread,
Dec 14, 2016, 11:09:41 AM12/14/16
to Keith Hughes, Fraser Goffin, Nexus Users
On Wed, Dec 14, 2016 at 10:14 AM, Keith Hughes <keith....@gmail.com> wrote:
Hi Brian,

For me I am more interested in 1. Part of it is to do with expanding the attack service, as Fraser put it, if people know what is there it is easier to encourage probing there, but also to not leak information about the organization outside of the organization. While one can argue that knowing I have a private PyPi repo doesn't say much, it is talking about things that are going on inside the company that seems best left private.

From a UX perspective, it is also a bit odd to be able to see a repo that always looks empty for many folks. Is it empty, or is it just private?

As for 2, I would imagine having the URL should fail for anonymous access if the UI would never show you the thing in the first place. That seems like a security breach waiting to happen.

You say the read permission as a filter for view in the UI is a pending issue. Any idea when it will be completed?

Its very near the top of the list competing with some other popular asks like the initial HA and (for Frasier) some more REST APIs...

Keith Hughes

unread,
Dec 14, 2016, 11:37:26 AM12/14/16
to Brian Fox, Fraser Goffin, Nexus Users
Ahh, cool. Thanks Brian. I will keep tabs on the release notes.


Daniel MD

unread,
Dec 18, 2016, 5:11:00 PM12/18/16
to Keith Hughes, Brian Fox, Fraser Goffin, Nexus Users
Nexus 3.1 behaves differently from 3.0. In 3.0 users that did not have access to the repo would not see it listed (anonymous disabled), therefore if I created repo npm-test and npm-user only had access to that repo he would only see that repo. That is the correct behavior.

In Nexus 3.1 they see all repos listed if they have or not have access, this is not a desirable behavior be it in terms of UX (more for the user to get lost) or security (people now what types of repos exist and can target attacks in case of vulnerability), and neither its good for privacy, if I have multiple tenants they should not know about the assistance of each other.

 I have found this issue by configuring an open source crowd plugin I thought it was the plugin that had a bug https://github.com/pingunaut/nexus3-crowd-plugin/issues/27 but as it turn out it appears to be a bug or regression in 3.1. 

The behavior should be, that users only see listed repos that they have access to. In our case we have certain teams/tenants that want to have their own separate repo, instead of a community one, the other teams/tenants should not know of the existence of these private repos.

 

Best,
-Keith


--
You received this message because you are subscribed to the Google Groups "Nexus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nexus-users...@glists.sonatype.com.

To post to this group, send email to nexus...@glists.sonatype.com.

--
You received this message because you are subscribed to the Google Groups "Nexus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nexus-users...@glists.sonatype.com.

To post to this group, send email to nexus...@glists.sonatype.com.
To view this discussion on the web visit https://groups.google.com/a/glists.sonatype.com/d/msgid/nexus-users/CALJKi6WcCKXU%3D14NNFLRgOY0LyUP-pQZeKU_J73gHUoF4eAdEA%40mail.gmail.com.

Mahendra

unread,
Dec 19, 2016, 7:48:04 AM12/19/16
to Nexus Users, keith....@gmail.com, bri...@sonatype.com, gof...@gmail.com
Hi Dan,

There is a jira raised for the issue of Nexus 3.1 showing all repos listed in Browse Assets/Components.


Regards,
Mahendra

Dan Mendes

unread,
Dec 19, 2016, 10:32:48 AM12/19/16
to Nexus Users, keith....@gmail.com, bri...@sonatype.com, gof...@gmail.com
Thank you Mahendra. I am tracking it now. Hope it makes it to 3.2 since it appears to be a regression.
Reply all
Reply to author
Forward
0 new messages