[Feature Request] Introduce `user.name` operand

[Dietr1ch]

Summary:

Today you can write rules matching a user's Id (as in id -u $USERNAME), but when writing rules it's easier to refer to user names.

Introducing the user.name operand can make maintaining rules easier.
Implementation wise, we can at some point (reading, compiling rules) translate it to user.id to avoid matching strings.

Why?

While the UI helps selecting the Id, there's some issues with this,

• Rules are harder to share across machines since User Ids may change (different distros or user creation order).
• Rules are harder to generate
  • (On NixOS we can write rules in the system config, but can't hardcode Ids as those haven't been picked for users/groups that don't exist yet)
• Rules are harder to read.
  • I'm not sure why, but some rules don't show a user name, only some Id that looks quite obscure.

[gustavo-iniguez-goya]

This has been requested several times #1116

One of the problems is if there's a new user added after the daemon is launched. We could monitor /etc/passwd for changes, and reload the list of usernames accordingly.

I'll write a PoC for this and see how it goes.

[gustavo-iniguez-goya]

The PoC is simple and works fine. We could filter also by Gid/Group.

  if o.Operand == OpUserName && o.Type == Simple {
      u, err := user.Lookup(o.Data)
      if err != nil {
              return fmt.Errorf("User name error: %s", err)
      }
      log.Trace("user.name: %+v\n", u)
      o.cb = o.simpleCmp
      o.Data = u.Uid
  }

  "operator": {
    "type": "simple",
    "operand": "user.name",
    "sensitive": false,
    "data": "arpalert",
    "list": []
  }

The second piece of this request would be to react to users list changes: disable a rule if the user/group is deleted.

We should also take into account (or the admin creating this rule) that a user may not exist in all machines where a rule is applied. In this case an error will appear on the RulesEditor dialog.

[gustavo-iniguez-goya]

another limitation when filtering by username for now will be, that the RulesEditor dialog won't display a list of available users, unless the selected node is local (i.e.: the node addr is a local IP or unix socket).

[gustavo-iniguez-goya]

Another thing to take into account is containers. Username X may have UID 1000 in the host and 100 in a container, so connections from user X initiated from a container won't be filtered by a rule if the UID differs.

[Dietr1ch]

Another thing to take into account is containers. Username X may have UID 1000 in the host and 100 in a container, so connections from user X initiated from a container won't be filtered by a rule if the UID differs.

BTW, this mismatch is also around for groups, maybe it's less likely if using the same distro, but still a pitfall that may need a small note on a tooltip to make it clear.