A global permission is required to view a specific repository

[johnnyaug]

The fs:ReadConfig permission on the resource "*" is required when viewing a specific repository from the UI.

[codeaucafe]

Not sure if this issue is planned for anyone, but I'd be happy to assist in fixing this bug if no one is tasked with this Issue yet.

[johnnyaug]

Hey @DataDavD, thank you, it would be great! I'm assigning you.

[codeaucafe]

Thanks @johnnyaug. FYI, I will be out of town this weekend, so I will most likely start really working on this issue (as well as Issue #2316) when I return Monday next week (hopefully that isn't an issue).

Thanks again for the help and letting me contribute to lakeFS.

best,
dd

[codeaucafe]

Hey @johnnyaug just wanted to provide a little update. I'm starting to look at this more thoroughly tonight. Currently I'm trying to follow some of the implementation and declaration paths so I know what function/method should be checking for this specific perms.

I will probably have more detailed questions tomorrow or Wednesday. Do you happen to know which function/methods I should focus on making sure they check fs:ReadConfig? In mean time I will reach out to lakeFS slack channel if I need any other help.

Thank you!

[itaiad200]

Hey @johnnyaug, not sure I understand what's wrong here. The ReadConfig allows one to read a config which is not unique to any repository. The returned struct is:

	StorageConfig{
		BlockstoreType
		BlockstoreNamespaceValidityRegex
		BlockstoreNamespaceExample
	}

The last 2 are lakeFS values and has nothing to do with the installation, the first one is the installation blockstore type. Why do you think that we need per-repo permissions here? Or do you think that we need to simply add the fs:ReadConfig:* to the default FSReadWriteAll policy as well?

[arielshaqed]

@itaiad200 I think the issue resides elsewhere. The function GetStorageConfig requires permissions for all repositories. That sort-of makes sense (its semantics are not tied to a specific repository).

But in practice the GUI uses this function on the RepositoriesObjectPage, to get ObjectsBrowser configuration. So if you don't have fs:ReadConfig on all repositories, I guess you cannot view objects in any repository.

Perhaps we need another, better-named, API endpoint in Swagger (GetRepositoryStorageConfig?). It will fetch the required properties for the repository, and will be able to apply more fine-grained permissions.

@DataDavD: The first step is to map what the objects page (see above) reads from the configuration. With that information you should be able to propose what information we really want to return. Does this make sense?

[johnnyaug]

I basically agree with @arielshaqed.

Simply put, as a lakeFS admin if I want to give my user permissions only for repo A, I have to give them this permission, which looks weird. It is implied by the name of this permission that it may allow access to installation-wide information. As a developer, I may be tempted to use this permission for other, more sensitive endpoints.

If we go with @arielshaqed's suggestion - we can remove this permission and protect the proposed endpoint with the existing fs:ReadRepository permission.

[itaiad200]

Thanks @arielshaqed & @johnnyaug for the clarifications. I agree with your suggestions.
@DataDavD is the path forward clearer now?

[codeaucafe]

hey @itaiad200 and @arielshaqed sorry for the delayed response (been busy with work/life - the normal 😄 ).

Thank you very much for the detailed explanations. I believe I have a much better starting point now, if I have any questions later on I'll be sure to ask them. I will also provide a bit more updates once I'm in the thick of the code changes (which I intend to start regularly working on this this week).

Thanks again for all y'all's assistance.

Best,
David