breeze on setgid executables

AlexL

This is probably as much an Altair-internal question as it is one for the community, but I'd expect others have run into this as well so maybe there is some knowledge in the community.

When trying to profile a python script I ran into an issue with breeze refusing to / being unable to trace the executable (`python`) because that had the setgid bit set.

The particular python version is part of a (shared) conda environment, so I have to assume that the setgid bit was set as part of that, but I don't know why or whether that's necessary.

Has anybody experienced this (with python or other executables) and has come up with a "workaround" other than removign the setgid bit? Question to the Altair/Ellexus team: are there any ways to side-step that restriction?

Alex

JayW

So Alex, good question. I looked through the docs but could not find anything so I decided to run some simple tests and I could not get it to break. There permissions on my setgid executable test was '-rwxr-sr-x' and I used Breeze version 2024.1.0. It seemed to work fine for me. I will also ask Altair engineering also but perhaps we should get a screen share and take a look at it?

• Jay

AlexL

Thanks Jay.

In short, yes, please - that may be the easiest, it seems
I can confirm the permissions, maybe with the caveat that I am NOT the owner of the executable and NOT member of the group, either - not sure whether that would make a difference.
I am using breeze 2024.1.0 as well.

So a live session might be easiest to get to the bottom of this.

and yes, for the fun of it, I tried to trace the trace-program.sh script, but apparently recursive use is frowned upon :-)

Alex

JayW

After discussion with engineering it was determined that breeze uses LD_LOAD_PATH and will not trace a setgid/setuid program unless your login is already the same as the effective gid of the program. This is a security mechanism built into linux to prevent injection of malicious libraries.

After talking with Alex, his environment was a 'condo environment for someone other than him and, for some reason, it does a setgid on the python executable. The sticky bit was also set on most all the directories (which forces new files to use the group of the directory). Since Alex didn't care to write anything into the 'conda' environment, we copied the 'python' executable outside of the 'condo' environment so it was no longer setgid and the breeze trace seemed to run fine.

Obviously, this solution won't work in all situations but it is one way to still utilize breeze while maintaining a secure environment.