Running /w Supplemental Groups

[upc-djw]

Is there a way to run scripts with supplemental groups (for the Shell Script plugin)? I noticed that I can set a group ID to run as, but I need the user the scripts run as to retain all of their supplemental groups in order for files to make their way where they are supposed to go.

When I have a script run "id" it indicates that the user is only getting one group, but when I run "id user1" it shows all of the groups that that user should be getting.

`id:
uid=31001(user1) gid=31000(primarygroup) groups=31000(primarygroup)

id user1:
uid=31001(user1) gid=31000(primarygroup) groups=31000(primarygroup),31002(group01),31003(group02),31004(group03),31005(group04),31006(group05),31001(user1),31007(group06),31008(group07),31009(group08),31010(group09),31011(group10)`

If I run commands with "sudo -u user1 COMMAND" it does get all of the groups, but I'd prefer not to have to run scripts in this manner if possible.

Thank you very much for your help!

[jhuckaby]

Thanks for the clear example. I was actually able to easily reproduce this outside of xyOps with a small Node.js script:

console.log( require('child_process').execSync('id', { encoding: 'utf8', uid: 1000 } ) );

When I run this as root, I get:

uid=1000(jhuckaby) gid=0(root) groups=0(root)

All my supplemental groups are missing, which is exactly what you are reporting in xyOps.

So, after some research, I found that this is actually a well-known libuv (Node.js) behavior, not a xyOps-specific bug. When a privileged Node.js process launches a child with a uid or gid option, libuv clears the child’s supplementary groups before setting its UID and GID. It does not then load the target user’s group memberships. xySat uses that same Node.js child process API to launch Plugins.

This also explains why id user1 shows all the expected groups while plain id inside the job does not. The former looks up user1 in the system’s user and group database; the latter reports the groups the running process actually has.

I'm working on how to address this for Plugin jobs, but it may be a while. Supplementary groups need to be initialized before the child gives up its privileges, so it may require a rather nasty shell workaround or launcher helper. Ugh...

I'll update this discussion when I have a practical solution, but it sure doesn't look like there is an easy, low-hanging fruit fix here...

[jhuckaby]

I'm working on a fix, but it's going to require changes in both xySat and xyOps. It might take a while for both releases to go live, but I'll update this thread when they do.

[upc-djw]

Thank you very much for looking into this! By chance do you have an ETA (i.e. days/weeks/months) for the fix?

I am working on a proof-of-concept for xyOps and am very impressed with it so far. We have a lot of scripts that would require the supplemental groups to run though, so I don't know how much further I can go in my POC until the supplemental groups can make their way through.

No worries if there isn't an ETA yet, I just thought I'd ask. Thanks again! 😃

[jhuckaby]

Thanks for the kind words! I understand why this is important for your POC if many of your scripts depend on supplementary groups.

I've started working on the fix. My rough estimate is about a week, assuming testing goes smoothly. It requires coordinated changes and releases for both xySat and xyOps, so I don't want to promise an exact date. I'll update this thread when there’s something ready to test.

I maintain xyOps independently, and community support here is best effort. If your team is considering xyOps for production and would benefit from a more structured support channel, you can find my support plans here. They help sustain the project and include prioritized product feedback. Either way, I appreciate you giving xyOps a try and explaining what your POC needs.

[upc-djw]

Awesome thank you SO much! 😃

We would definitely be getting a support plan after a successful POC. Thanks again!

[jhuckaby]

Okay, I have just released xyOps v1.1.3 and xySat v1.1.1. Once you update both on all your servers, you will be able to edit any Plugin and enable sudo wrapper mode:

This will preserve and pass along the correct UID/GID, as well as all the user's supplemental groups, to the child process running the job.

You can also customize sudo mode per-event, just like you can do with the UID/GID. Just add a plugin parameter with ID sudo, which must be a checkbox, and must be Administrator-locked. This way you can enable/disable the sudo wrapper per each event.

I updated the guide to include the sudo parameter override: https://github.com/pixlcore/xyops/wiki/Customize-UID-Per-Event

Hope this helps!

Enjoy!