Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
plugins: Plugin ideas added #2169
Most of the comments from the previous review are still not fixed.
I updated the documentation.
Concerning the "named" recursion it would be interesting to have your feedback.
Thank you. Quite some problems in error/specification and METADATA.ini.
referenced this pull request
Aug 22, 2018
I would also suggest renaming the recursion plugin to
An example of such reference checking without recursion would be the references to driver configurations in the lcdproc server configuration.
I would also suggest either closing this PR entirely and opening separate PRs for the proposed plugins, or at least opening a separate PR for the recursion/reference plugin, to keep things a bit more organized.
Yes, please let us open a new PR once we decided on the new name. If the checks are not limited to recursive checks, it makes sense to rename it. How can a user distinguish if a reference check is recursive or only a single check? What if we remove the old "struct" check and call the new plugin also "struct"? Is this plugin able to check some arbitrary recursive structure of configuration?
Btw. if possible we should avoid "override" because this already has a meaning within Elektra (it is a link to be preferred, see doc/METADATA.ini).
[/tests/keywithref] check/reference = ref [/tests/keywithrec] check/reference = ref check/reference/recursive = true
An alternative would be the following:
[/tests/keywithref/ref] check/reference = single [/tests/keywithrec/ref] check/reference = recursive
Here the type of
Personally I like the second option better. It makes more sense to me to specify the metadata on the actual reference key.
The current proposed plugin would only check references. Checking the remaining structure could simply be done with the
[/tests/base/ref] check/reference = recursive check/reference/restrict = typeA [/tests/base/typeA/_/name] check/type = string ; etc [/tests/base/typeA/_/size] check/type = long ; etc
The basic idea is to restrict the references to a certain path
Yes, I also like the second option better.
Good example. Could you please incorporate it into the README? But please continue using typeA (if I understood correctly it is changed to X later in the explanation).
The problem lies in the
Is is a bit difficult to explain:
So it is absolutely required that check/permission/user and check/permission/types are both present.
I hope I could explain the problem so that it is understandable. Do you have a better solution or do we simply require the coexistence of both metadatas?
What is "check/permission/types"?
I am not sure if it is fruitless. There are now many kernel extensions (and also file system features) to disallow root to do something. And I would prefer the "current user" and not root as default. And in the "current user" scenario no switching of egid is necessary.
If two options are absolutely required so that the plugin can do something useful it is of course possible to demand the presence of both options. Afaik this would be the first plugin, though.
It is used for the actual permissions, e.g. "rwx"
I wish for the same but when programming I could not circumvent the problem described above. But I have to switch egid since access only checks with one egid active. If you wish I could also demonstrate it on our next Elektra meeting.