plugins: Plugin ideas added #2169

ghost · 2018-08-08T11:56:09Z

I want to propose 3 new plugin ideas. For the recursion plugin I will need some more advise though from more experienced programmers.

markus2330

Thank you, there are good ideas!

markus2330 · 2018-08-08T12:19:31Z

src/plugins/path/README.md

@@ -24,9 +25,45 @@ is allowed to occur for both device and mountpoint. When checking for
 relative files, it is not enough to look at the first character if it is
 a `/`, because remote file systems and some special names are valid, too.

+If `check/permission = [permission], [user]` is also present it will check for the correct permissions


check/permissions also needs to be added to infos/metadata and doc/METADATA.ini

markus2330 · 2018-08-08T12:20:48Z

src/plugins/path/README.md

@@ -24,9 +25,45 @@ is allowed to occur for both device and mountpoint. When checking for
 relative files, it is not enough to look at the first character if it is
 a `/`, because remote file systems and some special names are valid, too.

+If `check/permission = [permission], [user]` is also present it will check for the correct permissions
+of the file/directory. `check/permission = rw, tomcat` for example will check if the user `tomcat` has read and 


Its better to separate permissions and ownership.

For ownership an option to refer to the "current" user would be interesting.

What about check/permission = rwx and
check/permission/user = tomcat in order to split up the permission and ownership?

When the user types in "current" in the user part, I would simply replace it with the user who caused the "kdb set". Does this make sense for you?

What about check/permission = rwxand
check/permission/user = tomcat in order to split up the permission and ownership?

The ownership has actually little to do with permission. So maybe check/owner/user and check/owner/group?

When the user types in "current" in the user part, I would simply replace it with the user who caused the "kdb set". Does this make sense for you?

This would create a problem if there is a user called "current". What about an empty string? I think this is not allowed as actual user name.

My question here is, if the owner is actually that much needed.
I just want to check if a certain user can read/write/etc. on a certain file.

If for example user "java" can write to /var/log/abc.log. Why is the owner of the file of any relevance?

You are right, it makes sense to make this check as simple as this.

So the "user" refers to for whom the permissions are checked, not to the owner. This should be said very clearly, not only hidden in the example.

markus2330 · 2018-08-08T12:22:31Z

src/plugins/path/README.md

+ Permissions available:
+ - `r`: **R**ead
+ - `w`: **W**rite
+ - `x`: e**X**ecute


I think you can fully implement this, missing are:

sticky bit

and then all of these permissions also for groups and others

Alright, I will add it in the next commit!

If you agree and have/will fix it, a "thumbs up" 👍 or similar is enough.

The sticky bit does not change the behavior of the program at all so I think it is better to ignore it.

I am thinking the same about groups. In the end its a a user who executes or uses the file in the setting. So probably its the best to keep it that simple and only provide rwx.

I am unclear now if you really want to split up permission and user as for me it is more intuitive to have them both in one metadata, eg. check/permission "rwx, java" (or maybe without the colon). If check/permission "rwx, " is given, the current user is taken?

In the implementation it matters: if the file does not exist, it is the sticky bit of the parent directory which may decide if the user can create the file.

Btw. did you check if there an "access (2)" which allows us to say for which user it should be checked? Then the implementation would be trivial.

Maybe there should also be a flag if the file already needs to be present. For log files there are many differences in this area. Actually, if the software does not allow the creation of files, we could simply create it.

I am unclear now if you really want to split up permission

Yes, the split is a must. Otherwise we get problems if the user names contains ",", spaces or similar.

Btw. did you check if there an "access (2)" which allows us to say for which user it should be checked? Then the implementation would be trivial.

Unfortunately I do not understand what you mean by this 😕

Maybe there should also be a flag if the file already needs to be present. For log files there are many differences in this area.

Maybe we could add a check/path/exists setting which indicated if it has to exist already?

Actually, if the software does not allow the creation of files, we could simply create it.

The idea sound good but especially with logs there are rollovers and this could simply lead to a delayed configuration error which isn't wanted. I guess the user setting the specification should just give the executing user the creation (write) permission to the directory.

Yes, the split is a must. Otherwise we get problems if the user names contains ",", spaces or similar.

What about

check/permission = rw

check/permission/user = tomcat

?

Unfortunately I do not understand what you mean by this confused

I mean to use the syscall access (2) http://man7.org/linux/man-pages/man2/access.2.html

logs there are rollovers and this could simply lead to a delayed configuration error which isn't wanted.

Yes, this is certainly not wanted. I think we need to gather more data here for what applications do here.

One more advanced idea is that Elektra already opens a file and then passes /proc/self/fd/ instead of the real file name. Then it is impossible that the file disappears (but it needs additionally resources, namely an open file descriptor).

What about

Simply propose it in the PR. We can take a look tomorrow.

markus2330 · 2018-08-08T12:23:01Z

src/plugins/path/README.md

+ - `r`: **R**ead
+ - `w`: **W**rite
+ - `x`: e**X**ecute
+


Checks for regular file/directory/symbolic link/... would be interesting, too. But they are only nice-to-have.

I will leave this open for now and see in my thesis if it is needed that often. But the idea is good!

Yes, making everything complete is not a good idea anyway. It easily happens that stuff is added nobody ever needs. I just mentioned it so that you are aware that such a check might be relevant for some software.

markus2330 · 2018-08-08T12:23:54Z

src/plugins/path/README.md

+kdb set /tests/path/value /var/log/application-file.log
+
+#This checks if the file actually exists
+kdb setmeta user/tests/path/value check/path


sudo kdb setmeta /tests ...

to use keys in spec.

markus2330 · 2018-08-08T13:31:49Z

src/plugins/recursion/README.md

+3) Forcing users to define non-recursive settings first on which they can build up 
+recursive settings is inconvenient and could lead to orphan settings.
+4) We can only check right after calling `kdb set` and not a whole config. 
+This means that user can have "unfinished" configurations while setting new values.


I do not understand this limitation. Within "kdb set" you can check the whole configuration and reject everything that is unfinished.

That's correct, but this would force the user to have a specified ordering when creating the configuration. Either "bottom-up" (you have to create leaf settings before recursive ones) or "top-down" (you have to create top level settings first before adding lower level ones).

Klemens said that some plugins which take a config do not have a specific ordering once you load them.

Some storage plugins do not remember the order of entries within the configuration files. But the order of the configuration structure should have nothing to do with that.

markus2330 · 2018-08-08T13:36:12Z

src/plugins/recursion/README.md

+```
+kdb mount config.dump /recursive dump recursion
+kdb setmeta user/recursive check/recursion/vertex "menu, submenu"
+kdb setmeta user/recursive check/recursion/leaf "param, menupoint"


Please use Elektra arrays, for example:

kdb setmeta user/recursive check/recursion/vertex/#0 menu kdb setmeta user/recursive check/recursion/vertex/#1 submenu kdb setmeta user/recursive check/recursion/leaf/#0 param kdb setmeta user/recursive check/recursion/leaf/#1 menupoint

See #1010

A kdb set-meta-array would be nice to have.

markus2330 · 2018-08-08T13:38:11Z

src/plugins/recursion/README.md

+
+`check/recursion/vertex` basically means that keys containing `menu` or `submenu` after `/recursive`
+will have further configurations below them. So users would build up structures like this:
+`/recursive/<vertex>/#[0-9]+/<vertex>/#[0-9]+/.....`


Can you give a concrete example? Why is #[0-9]+ allowed?

I will change the example in the next commit

markus2330 · 2018-08-08T13:39:14Z

src/plugins/recursion/README.md

+will have further configurations below them. So users would build up structures like this:
+`/recursive/<vertex>/#[0-9]+/<vertex>/#[0-9]+/.....`
+
+`check/recursion/leaf` means that there is no subvertex allowed anymore. So this is not allowed:


What does "param, menupoint" mean?

I will change the example in the next commit

markus2330 · 2018-08-08T13:40:00Z

src/plugins/recursion/README.md

+
+A command will fail if users want to set settings for non-existent vertices, eg. `kdb set /recursive/menu/#5/....`
+
+The validation solely happens on the structure, not on the values of the keys.


Yes, it makes sense to separate this.

markus2330

Most of the comments from the previous review are still not fixed.

markus2330 · 2018-08-09T09:48:28Z

doc/METADATA.ini

+status= idea
+usedby/plugin= path
+type= string
+description= A check to see if a certain user has correct permissions on a file


How to specify the user? Specification of which values are allowed are missing.

how to specify any combination or rwx?

There are many ways, I am sure you will find one 😄

well, of course I could find one but I have no idea what this file does or how it is used or if it is used. I mean I could provide a regex under "type" or enumerate all possibilities or give a textual description. But I have no idea if I break anything or if I write something illegal then. Is there any documentation for this?

markus2330 · 2018-08-09T10:05:24Z

src/error/specification

@@ -1209,3 +1209,9 @@ severity:error
 ingroup:plugin
 module:typechecker
 macro:PLUGIN_TYPECHECKER_SET
+
+number:194
+description:The given path does not meet the correct permissions


We should try to reuse/reduce the errors and make a nice classification system. Hopefully you can contribute to improve the error system.

markus2330 · 2018-08-09T10:06:42Z

src/plugins/network/README.md

+## Future Work
+
+`check/port/ping` to check if the port can be pinged/reached (usually for clients).
+This potentially could prohibit users from setting correct settings as the server application


Not if it is a warning.

The problem is rather that a timeout is needed.

markus2330 · 2018-08-09T10:08:02Z

src/plugins/path/README.md

@@ -26,7 +27,7 @@ relative files, it is not enough to look at the first character if it is
 a `/`, because remote file systems and some special names are valid, too.

 If `check/permission = [permission], [user]` is also present it will check for the correct permissions
-of the file/directory. `check/permission = rw, tomcat` for example will check if the user `tomcat` has read and 
+of the file/directory. `check/permission = rw` and `check/permission/user = tomcat` for example will check if the user `tomcat` has read and 


There is still no explanation of check/permission, check/permission/user. It is good to have an example but there should also be an explanation without example.

markus2330 · 2018-08-09T10:08:31Z

src/plugins/path/README.md

@@ -48,10 +49,10 @@ sudo kdb mount some_file.ecf /tests/path some_file dump
 kdb set /tests/path/value /var/log/application-file.log

 #This checks if the file actually exists
-kdb setmeta user/tests/path/value check/path
+sudo kdb setmeta user/tests/path/value check/path


"user" needs to be removed, otherwise the change does not make sense.

markus2330 · 2018-08-09T10:09:06Z

src/plugins/path/README.md

-# RET:X
-# ERROR:XXX
+# ERROR:194
+# Reason: User tomcat has no permission to read the given file.


Reason should state what was expected and what is actual.

markus2330 · 2018-08-09T10:09:43Z

src/plugins/recursion/README.md

@@ -23,25 +23,37 @@ Users have to define recursive setting specifications in the following way:

 ```
 kdb mount config.dump /recursive dump recursion
-kdb setmeta user/recursive check/recursion/vertex "menu, submenu"
-kdb setmeta user/recursive check/recursion/leaf "param, menupoint"
+kdb setmeta user/recursive check/recursion/vertex "A, B"


Still without array syntax.

I will take a look at it on the weekend. For understanding purposes I think it is fine

It is not easy to review something which actually should be changed.

markus2330 · 2018-08-09T10:10:22Z

src/plugins/recursion/README.md

 ```

-`check/recursion/vertex` basically means that keys containing `menu` or `submenu` after `/recursive`
-will have further configurations below them. So users would build up structures like this:
+`check/recursion/vertex` basically means that keys containing `A` or `B` after `/recursive`


The word "basically" is useless. Say it like it is. And again: with+without example.

ghost · 2018-08-10T14:02:48Z

src/plugins/recursion/README.md

@@ -81,10 +81,186 @@ kdb set /recursive/define/#2/ref/#1 /recursive/define/#5
 Arbitrary additional data can be saved too such as:
 `kdb set /recursive/define/#2/permission admin`

+## A more real example


@markus2330 I hope that this example is much more illustrative for you. Please take a look at it and tell me anything which is unclear. It really took me quite some time to get this right

markus2330

Thank you, much more clear now!

markus2330 · 2018-08-11T08:04:13Z

src/plugins/recursion/README.md

@@ -81,10 +81,186 @@ kdb set /recursive/define/#2/ref/#1 /recursive/define/#5
 Arbitrary additional data can be saved too such as:
 `kdb set /recursive/define/#2/permission admin`

+## A more real example
+
+In order to better show how this plugin can be used, a more sophisticated example will be given.


Its better if the examples show different aspects, not one "less real" and another "more real".

markus2330 · 2018-08-11T08:04:37Z

src/plugins/recursion/README.md

+## A more real example
+
+In order to better show how this plugin can be used, a more sophisticated example will be given.
+Imagine that you want to create your own menu with arbitrary submenus possible. The following example


Menu like in a restaurant?

markus2330 · 2018-08-11T08:06:47Z

src/plugins/recursion/README.md

+The following picture illustrates the menu tree:
+![menu-example](example.png?raw=true "Example")
+
+So how can we map this into an elektra configuration?


configuration or specification?

markus2330 · 2018-08-11T08:07:33Z

src/plugins/recursion/README.md

+```
+kdb mount config.dump /editor dump recursion
+sudo kdb setmeta /editor check/recursion/vertex "menu"
+sudo kdb setmeta /editor check/recursion/ref "menuref"


Specification still not explained, what are these two lines for?

markus2330 · 2018-08-11T08:33:00Z

src/plugins/recursion/README.md

+sudo kdb setmeta /editor check/recursion/vertex "menu"
+sudo kdb setmeta /editor check/recursion/ref "menuref"
+```
+Each key definition in the form of `/editor/menu` will now be treated as recursive entry. You can define arbitrary


/editor/menu is not a form but rather an example?

markus2330 · 2018-08-11T08:39:07Z

src/plugins/recursion/README.md

+```
+#Link "Macro Basics" to the parent menu "Macros" and create an endless loop
+kdb set /editor/menu/#9/menuref/#0 /editor/menu/#7
+ERR: 198


Please use shell recorder syntax

Do you have a link to a tutorial for that?

The following documents should be helpful:

ReadMe of the Markdown Shell Recorder (MSR)

the MSR syntax check

. Many of the plugins also contain some basic MSR tests. For example, the ReadMe of YAML CPP contains a few example tests.

markus2330 · 2018-08-11T08:39:54Z

src/plugins/recursion/README.md

+#Link to something which does not exist
+kdb set /editor/menu/#9/menuref/#0 /editor/menu/#10
+ERR: 199
+Reason: Could not find vertex with #10. Maybe it does not exist yet?


Why isn't the term also used in the tutorial?

markus2330 · 2018-08-11T08:44:20Z

src/plugins/recursion/README.md

+Their approach is not array based but name based. 
+Their reference keyword (`check/recursion/ref`) to other settings is `Entry`.
+
+They do not use an array based approach though but give names instead.


Can we add a name-based approach or does it confict with the array-based approach?

It doesn't conflict imo, as discussed in your comment below it needs to know if it is a vertex or some arbitrary setting unrelated to the recursive structure. With the array based approach this is clear.

Imho, the array does not make a difference. Without some external knowledge you never know if a string is a reference or a value interpreted otherwise.

markus2330 · 2018-08-11T08:44:52Z

src/plugins/recursion/README.md

+kdb set /editor/AutocorrectOptions/DisplayName "Autocorrect Options"
+``` 
+
+This would at least guarantee reusability of settings.


Why "at least"? What is missing?

markus2330 · 2018-08-11T08:45:09Z

src/plugins/recursion/README.md

+This would at least guarantee reusability of settings.
+
+The plugin could theoretically support an arbitrary name instead of an array. But how does the 
+specification know what is actually a menu entry and what is just some arbitrary other setting.


How could this look like?

ghost · 2018-08-11T10:55:19Z

I updated the documentation.
On sunday I will

Add src/error/specification for port & recursion
write the correct shell recorder syntax

Concerning the "named" recursion it would be interesting to have your feedback.
Also on the Problem part in the recursion plugin readme which I updated.

markus2330 · 2018-08-11T11:22:23Z

src/plugins/recursion/README.md

+[b]
+```
+
+which could cause an error since `a` cannot be loaded as `b` is yet non existent.


This order should not matter.

Can you explain why? How exactly are keys loaded into the kdb?

I assume that it is loaded in the order of the file, i.e. it would be the same if I call kdb set ... in the same order as the config file

The plugins receive a whole keyset and can do whatever they want to do with it. So in the implementation you can lookup if something is present, it does not matter where in the keyset it is.

ghost · 2018-08-16T09:21:11Z

I redesigned the recursion plugin to only have the "named" approach now. The array approach might be confusing and isn't superior. Now we can easily adopt LCDproc's configuration

markus2330

Thank you. Quite some problems in error/specification and METADATA.ini.

markus2330 · 2018-08-16T15:31:07Z

doc/METADATA.ini

+type= enum
+description= A check to see if a certain user has correct permissions on a file. Permissions are
+	either r (read) w (write) x (execute) and any combination of them.
+	 The respective user which must have these permissions is declared in check/permission/user.


What if check/permission/user is missing?

markus2330 · 2018-08-16T15:31:18Z

doc/METADATA.ini

+[check/permission]
+status= idea
+usedby/plugin= path
+type= enum


specify all cases.

markus2330 · 2018-08-16T15:31:38Z

doc/METADATA.ini

+description= A check to see if a certain user has correct permissions on a file. Permissions are
+	either r (read) w (write) x (execute) and any combination of them.
+	 The respective user which must have these permissions is declared in check/permission/user.
+example = "rwx ; rw ; r ; x ; w ; wx"


this is not an example, ; is not allowed.

What is a valid example? They are all just some descriptions as i can see. I made it more verbose now

The example needs to be something that actually could be a value of the metavalue.

E.g. "rwx" would be a valid example.

markus2330 · 2018-08-16T16:17:43Z

doc/METADATA.ini

+status= idea
+usedby/plugin= path
+type= string
+	empty


empty or string?

either or. If empty then the current user is taken, if a string is given it is interpreted as the desired user. It is also written in the description

string automatically includes empty. Elektra does not have sum types, so specifying "string empty" does not make sense. (The result would be "empty")

markus2330 · 2018-08-16T16:18:02Z

doc/METADATA.ini

+usedby/plugin= path
+type= string
+	empty
+description= Used be check/permission to see if the given user has the correct permissions. If empty


empty or non-existent?

Isn't it the same question as above?

Yes, it is the same problem.

markus2330 · 2018-08-16T16:25:42Z

src/error/specification

+module:network
+
+number:196
+description:The desired port is already in use.


Please be consistent with the already existing errors if you put a . in the end or not.

Some descriptions have a dot and some do not. Which one should i take now?

Ok, this is something to unify later.

We can also make that sentences get a .

markus2330 · 2018-08-16T16:26:05Z

src/error/specification

+description:Referring to the desired key would lead to an endless loop
+severity:error
+ingroup:plugin
+module:network


network or recursive?

woops, copy and paste error

markus2330 · 2018-08-16T16:27:31Z

src/plugins/network/README.md

@@ -14,6 +14,8 @@ This plugin is a check plugin that checks if a key contains a valid ip
 address. It uses the `POSIX.1-2001` interface `getaddrinfo()` in order
 to check if an ip address is valid.

+The plugin can also check for valid port numbers and if the set port is free to use.


The port should actually also passed to getaddrinfo. Better to rewrite the intro.

markus2330 · 2018-08-16T16:30:04Z

src/plugins/network/README.md

+
+## Future Work
+
+`check/port/ping` to check if the port can be pinged/reached (usually for clients).


maybe connect is better, as ping somehow implies ICMP.

markus2330 · 2018-08-16T16:32:09Z

src/plugins/recursion/README.md

 ```

+It is not needed to add `/recursive` before every key as it is only possible to choose keys
+below this rootkey anyway. Referring to other keys is done by 


directly below?

markus2330

small things...

markus2330 · 2018-08-18T09:51:18Z

doc/METADATA.ini

@@ -682,17 +682,24 @@ description= Support of some standards for a date specification.
 [check/permission]
 status= idea
 usedby/plugin= path
-type= enum
+type= r


enum and then the possibilities

markus2330 · 2018-08-18T09:51:35Z

src/error/specification

Its better to have a new-line in the end of files.

markus2330 · 2018-08-18T09:52:24Z

src/plugins/network/README.md

@@ -14,7 +14,9 @@ This plugin is a check plugin that checks if a key contains a valid ip
 address. It uses the `POSIX.1-2001` interface `getaddrinfo()` in order
 to check if an ip address is valid.

-The plugin can also check for valid port numbers and if the set port is free to use.
+Furthermore `getaddrinfo()` is used in `check/port` to resolve a port by its service name
+which is defined under `/etc/services`.


and it also transforms to the number?

ghost · 2018-08-18T17:32:45Z

Hopefully now everything is accordingly.

Could you take a look at the new recursion plugin? It just contains a single check metadata now instead of 2.

kodebach · 2018-09-08T14:44:45Z

@markus2330 I updated the recursion plugin README with results from a talk between me and @Piankero

I would also suggest renaming the recursion plugin to reference, because one major part of the work the proposed plugin would do is checking, whether references are valid. This functionality could also be useful elsewhere without the recursive part.

I propose:

changing check/recursion to check/reference
changing check/recursion/override to check/reference/override
changing check/recursion/restrict to check/reference/restrict
adding the boolean check/reference/recursive to enable/disable the check for loops in the reference graph

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.

markus2330 · 2018-09-08T15:45:44Z

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).

kodebach · 2018-09-09T12:08:27Z

How can a user distinguish if a reference check is recursive or only a single check?

[/tests/keywithref]
check/reference = ref

[/tests/keywithrec]
check/reference = ref
check/reference/recursive = true

Here /tests/keywithref/ref would just be a single reference, while /tests/keywithrec/ref would be checked recursively.

An alternative would be the following:

[/tests/keywithref/ref]
check/reference = single

[/tests/keywithrec/ref]
check/reference = recursive

Here the type of check/reference would be enum, with the values single and recursive being supported. The name used for recursive checking would be the basename of the key with the check/recursive metadata. Then overriding the name could be done through a third enum value.

Personally I like the second option better. It makes more sense to me to specify the metadata on the actual reference key.

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?

The current proposed plugin would only check references. Checking the remaining structure could simply be done with the spec plugin:

[/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 X and then using X as a kind of type identifier. The direct sub-keys of X would then be 'instances' of X, so by using X/_/Y one can specify properties of the field Y of typeX.

markus2330 · 2018-09-09T20:10:01Z

Personally I like the second option better. It makes more sense to me to specify the metadata on the actual reference key.

Yes, I also like the second option better.

The basic idea is to restrict...

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).

ghost · 2018-09-16T15:59:46Z

@markus2330
There is a problem with the extension of the path plugin and the assumption if the metakeycheck/permission/user is not set, the current user is taken.

The problem lies in the euidaccess function and the need to change the egid.

Is is a bit difficult to explain:
*) euidaccess checks for the access with the egid and euid.
*) unfortunately there can only be one egid active at a time when calling euidaccess().
*) So if a user belongs to multiple groups and the filegroup is one of them, I have to actively switch to this group with setegid() before calling euidaccess()
*) To switch via setegid() I have to be running as root even though I am a member of the group I want to "switch" to.
*) When running as root though, the information is lost for which user you really want to check the permission for.

So it is absolutely required that check/permission/user and check/permission/types are both present.
I can only support to assume if check/permission/user is empty the root user is assumed. But checking for file access as root user is a bit fruitless.

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?

markus2330 · 2018-09-21T09:18:36Z

What is "check/permission/types"?

But checking for file access as root user is a bit fruitless.

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.

ghost · 2018-09-22T20:10:18Z

What is "check/permission/types"?

It is used for the actual permissions, e.g. "rwx"

And I would prefer the "current user" and not root as default. And in the "current user" scenario no switching of egid is necessary.

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.

ghost · 2018-10-13T15:44:55Z

All plugin ideas are now in implementation stage in their respective PR. Closing this PR

plugins: Plugin ideas added

b3c2e81

ghost requested a review from markus2330 August 8, 2018 11:56

markus2330 reviewed Aug 8, 2018

View reviewed changes

plugin: Some improvements

5114af7

markus2330 requested changes Aug 9, 2018

View reviewed changes

ZronekM added 2 commits August 9, 2018 13:19

plugins: enhanced plugin READMEs

61f6c46

plugin: Added a better example for the recursion plugin

1f290c9

ghost commented Aug 10, 2018

View reviewed changes

markus2330 reviewed Aug 11, 2018

View reviewed changes

recursion: Updated documentation

c12ffe2

recursion: added array notation sentence

756135d

markus2330 reviewed Aug 11, 2018

View reviewed changes

ZronekM added 2 commits August 15, 2018 17:18

Added Metadata and redesigned recursion plugin

f0a1b9b

Added error specification

810d1bd

ghost added the ready to merge label Aug 16, 2018

markus2330 requested changes Aug 16, 2018

View reviewed changes

markus2330 removed the ready to merge label Aug 17, 2018

Clarifications for plugins

af739e4

ghost added the ready to merge label Aug 18, 2018

markus2330 reviewed Aug 18, 2018

View reviewed changes

markus2330 removed the ready to merge label Aug 18, 2018

ZronekM added 2 commits August 18, 2018 12:04

Clarifications for plugins

ef44f83

Corrections

6780b69

ghost added the ready to merge label Aug 18, 2018

markus2330 mentioned this pull request Aug 22, 2018

network plugin does not allow localhost #2203

Closed

markus2330 removed the ready to merge label Aug 25, 2018

recursion: update contents of README.md

c830211

markus2330 mentioned this pull request Sep 9, 2018

default value calculation #2231

Closed

ghost closed this Oct 13, 2018

ghost deleted the plugin-proposals branch March 30, 2019 09:21

This pull request was closed.


		A command will fail if users want to set settings for non-existent vertices, eg. `kdb set /recursive/menu/#5/....`

		The validation solely happens on the structure, not on the values of the keys.


		## Future Work

		`check/port/ping` to check if the port can be pinged/reached (usually for clients).

plugins: Plugin ideas added #2169

plugins: Plugin ideas added #2169

Conversation

ghost commented Aug 8, 2018

markus2330 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markus2330 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markus2330 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Aug 11, 2018 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Aug 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Aug 16, 2018

markus2330 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Aug 11, 2018 •

edited by ghost

Loading