fix(install): run privileged user/ownership setup via sudo when installer is non-root (#753) - #754
Conversation
…ller is non-root (#753)
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe installer script ChangesPrivilege Handling and Permissions Hardening
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
On a non-root run where
have_root_or_sudosucceeds (passwordless sudo, the default on Radxa/Armbian SBC images),ensure_taos_usercalleduseraddandusermodbare without any privilege elevation, andset_data_dir_ownershipcalledchown -Randchmodthe same way, silently discarding errors via2>/dev/null || true. The service unit was still stamped withUser=taos, so the first start failed with 217/USER on a fresh box, or reproduced the #723 CHDIR restart loop on a box with a prior root install where the repair chown/chmod never actually ran.Both functions now compute
local sudo_cmdthe same wayinstall_linux_systemd_systemalready does (empty when already root,"sudo"otherwise), and prefix every privileged call with it. Thechown -Rand parent-walkchmod o+xfailures are no longer silenced: if either fails, a visiblewarntells the user the service will not start and to re-run with sudo. Thechmod 0700/0600tightening calls also receive the prefix. Closes #753; hardens the #723 scenario.Summary by CodeRabbit
Bug Fixes
Chores