=== tds8 is now known as tds [09:55] hi! I'm trying to deploy a (rocky8) vm with cloud-init and use `write_files` for some script in /usr/local/sbin (which works) but setting its SETUID bit using `permissions: '04111'` in the user data does not work, it's always present without setuid, i.e. permissions 0111 [09:56] I've tried `permissions: '0o4111'` and both without quotes in the yaml, but to no avail (currently testing locally with `sudo cloud-init single --name cc_write_files --frequency always` which rebuilds the file) [11:22] azrdev: the docs for write_file indicate that it is "represented as an octal string 'O###'" which implies that setting the setuid bit is not supported. However briefly looking at the actual cloud-init code I don't see this being enforced [11:38] minimal: i tried to follow the int/string type conversions in the code too, but got a bit lost. the final `os.chmod()` should support setuid, so probably I should report the matter as an issue? [12:40] azrdev: if you have debugging enabled then what appeared in the "Writing to ..." debug entry for that file? The mode_r value is part of that debug entry [13:26] minimal: /var/log/cloud-init.log contains "Writing to /usr/local/sbin/vault-deploy-certificates - wb: [4111] 379 bytes" (didn't need to enable debugging anywhere, though) [13:31] afterwards 2x "Restoring selinux mode ", dunno if the selinux policy contains modes in addition to labels [13:36] so the "4111" in the debug message appears to reflect the file mode including setuid [13:37] so then it seems like the chmod should enable the setuid [17:22] azrdev: minimal I found the issue here in testing locally. write_files calls util.write_file( mode=0o4111) correctly, then it calls `util.chownbyname(path, u, g)` which drops the setuid bit when chowning to a non-root user. azrdev please file an issue in github and we can work that fix or help shepherd a pull request if you'd like to put one up. I think we need to assert that requested perms are retained after chownbyname [17:22] example logs: 2025-05-15 17:24:24,400 - cc_write_files.py[DEBUG]: BEFORE chownbyname perms /home/testuser/my-file: 4111 [17:22] 2025-05-15 17:24:24,400 - util.py[DEBUG]: Changing the ownership of /home/testuser/my-file to 1000:-1 [17:22] 2025-05-15 17:24:24,400 - cc_write_files.py[DEBUG]: AFTER chownbyname perms /home/testuser/my-file: 111 [17:25] given that chown tries to drop setuid bits by default as a security measure, cloud-init invoking that call without asserting that the requested setuid is reset across chown system call is at fault here. [17:31] blackboxsw: I did also mention earlier that the c-i imply only the lower 3 bits can be used [17:31] s/c-i/c-i docs/ [17:34] yeah, I agree that it's implied by only 3 octothorp "#" characters in docs, yet, it should be possible to support it as we don't explicitly prevent that anywhere. It's just the side-effect of ordering chown to non-root user after write_files initial call. [17:34] could be a feature-request more than a bug :) [17:45] this'd probably do the trick https://dpaste.com/6DWEZDYC3