fix: improve gfxmode signal file creation safety

[52cyb]

1. Move gfxmode signal file from /tmp to /run for better tmpfs management
2. Introduce CreateGfxmodeDetectReady function to ensure safe atomic file creation
3. Use openat + O_NOFOLLOW + O_CREAT + O_EXCL for secure operations
4. Remove direct os.WriteFile calls in favor of the new function for consistency
5. Update systemd service to allow writes to /run/deepin-gfxmode-detect- ready

Log: Improved security of gfxmode detection signal file by relocating to /run and using atomic file creation

Influence:

1. Test gfxmode detection process with normal device conditions
2. Verify signal file creation in /run directory after detection completes
3. Test scenarios with pre-existing signal file or symlink attacks
4. Verify systemd service permissions allow writes to /run/deepin- gfxmode-detect-ready

refactor: 提升 gfxmode 信号文件创建安全性

1. 将 gfxmode 信号文件从 /tmp 迁移至 /run，改善 tmpfs 管理
2. 引入 CreateGfxmodeDetectReady 函数，确保安全的原子文件创建
3. 使用 openat + O_NOFOLLOW + O_CREAT + O_EXCL 进行安全操作
4. 移除直接的 os.WriteFile 调用，统一使用新函数
5. 更新 systemd 服务，允许写入 /run/deepin-gfxmode-detect-ready

Log: 通过将检测完成信号文件迁移至 /run 并使用原子创建，提升安全性

Influence:

1. 测试正常设备条件下的 gfxmode 检测流程
2. 验证检测完成后 /run 目录中信号文件的创建
3. 测试预先存在信号文件或符号链接攻击的场景
4. 验证 systemd 服务权限允许写入 /run/deepin-gfxmode-detect-ready

PMS: BUG-367565

[sourcery-ai]

Sorry @52cyb, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 52cyb

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

Hi @52cyb. Thanks for your PR.

I'm waiting for a linuxdeepin member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.