=== tds8 is now known as tds
[09:55] <azrdev> 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] <azrdev> 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] <minimal> 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] <azrdev> 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] <minimal> 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] <azrdev> 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] <azrdev> afterwards 2x "Restoring selinux mode ", dunno if the selinux policy contains modes in addition to labels
[13:36] <minimal> so the "4111" in the debug message appears to reflect the file mode including setuid
[13:37] <minimal> so then it seems like the chmod should enable the setuid
[17:22] <blackboxsw> 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] <blackboxsw> example logs: 2025-05-15 17:24:24,400 - cc_write_files.py[DEBUG]: BEFORE chownbyname perms /home/testuser/my-file: 4111
[17:22] <blackboxsw> 2025-05-15 17:24:24,400 - util.py[DEBUG]: Changing the ownership of /home/testuser/my-file to 1000:-1
[17:22] <blackboxsw> 2025-05-15 17:24:24,400 - cc_write_files.py[DEBUG]: AFTER chownbyname perms /home/testuser/my-file: 111
[17:25] <blackboxsw> 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] <minimal> blackboxsw: I did also mention earlier that the c-i imply only the lower 3 bits can be used
[17:31] <minimal> s/c-i/c-i docs/
[17:34] <blackboxsw> 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] <blackboxsw> could be a feature-request more than a bug :)
[17:45] <blackboxsw> this'd probably do the trick https://dpaste.com/6DWEZDYC3