Hey @jsoriano actually the best way here would be to make group reusable at process.group (and same for reusing user at process.user, for good measure).

This way we'll be able to map very simply to process.user.id and process.group.id, and also process.user.name and process.group.name if we desire.

WDYT?

@webmat I am outside my knowledge base, but have to ask:

1. Rather than nesting process.group.* couldn't we just populate process.* and group.* at the top level?
2. Rather than nesting process.user.*couldn't we just populate process.* and user.* at the top level?

I am concerned from an ECS perspective that we'll now have double-nesting of re-usable fields, such as user.*, user.group.*, process.user.*, process.group.*, process.user.group.* which is going to make this hard to understand.

@jsoriano Actually you make a good point. I was conflating your need with another discussion we've been having over here: elastic/beats#10192.

In this other situation, we are displaying all considered sources of information to determine the final / effective user and group ID. So the same event can potentially contain audit/effective/filesystem/saved/object IDs for user and group. In this case, it's necessary to nest everything in a structured manner.

But you're right that if you have an event that describes one process, then user.* and group.* at the top level should be used.

Take into account that this pgid doesn't identify a group of users but a group of processes, the kind of value would be the same as pid or ppid. I think it makes more sense in process.pgid.

I am concerned from an ECS perspective that we'll now have double-nesting of re-usable fields, such as user., user.group., process.user., process.group., process.user.group.* which is going to make this hard to understand.

+1, I think we should keep this information at user.*, group.*, if not it can be difficult to corelate different resources of the same users and groups [of users].

I have updated the description of the issue to remark that pgid identifies a group of processes.

@webmat I have updated the branch, let me know if I should do something else to get this merged.

Thanks @jsoriano. Regular work on improvements to ECS should slowly pick up again next week.

Don't worry, I have this on my todo :-)

@jsoriano Sorry for the time it took me to get back to working on ECS.

@MikePaquette @ruflin This is ready to be merged, and I think it's fine as is. This adds another abbreviation field, which I think is fine, because it's consistent with .pid.

Any objections to me merging this?

Heads up, I'll be merging this tomorrow.