feat: Allow usage of sudo [while not accessing root] in x.py

[gimbling-away]

Fixes

This PR should fix #93344

Info

Allows usage of sudo (while not accessing root) in x.py

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

[jyn514]

bootstrap.py should skip the check if SUDO_USER is not root, or an option to bypass this check should be provided

@gimbles could you change this to check SUDO_USER instead of adding more configuration options?

The place to add flags is in the argparse section near the bottom of bootstrap.py, but I don't think a new flag is the best approach.

[jyn514]

@rustbot label A-rustbuild

[gimbling-away]

bootstrap.py should skip the check if SUDO_USER is not root, or an option to bypass this check should be provided

@gimbles could you change this to check SUDO_USER instead of adding more configuration options?

The place to add flags is in the argparse section near the bottom of bootstrap.py, but I don't think a new flag is the best approach.

Sure!

But I don't think it will exactly fix OPs problem? The logs say that SUDO_USER is root

[jyn514]

The logs say that SUDO_USER is root

Ah, so they do. @chbaker0 can you confirm whether making the SUDO_CHECK smarter would help you or not? I do see that you're calling build.py and not x.py, so maybe you're changing the user there?

[chbaker0]

The logs say that SUDO_USER is root

Ah, so they do. @chbaker0 can you confirm whether making the SUDO_CHECK smarter would help you or not? I do see that you're calling build.py and not x.py, so maybe you're changing the user there?

My bad. Looks like SUDO_USER is the user who invoked sudo rather than who is being impersonated.

The sudo check can still be made smarter, by checking the regular UID. If sudo is not being used to run as root, instead just as a different user, then the user probably intended it.

build.py is just a helper script to check out, configure, and build Rust (using x.py) for use in Chromium

[jyn514]

The sudo check can still be made smarter, by checking the regular UID. If sudo is not being used to run as root, instead just as a different user, then the user probably intended it.

Sounds good :) I found that python -c 'import os; print(os.getuid())' works consistently to get the user ID; since bootstrap.py is already in python I think you can check this just with os.getuid() == 0 rather than looking at SUDO_USER at all.

[gimbling-away]

The sudo check can still be made smarter, by checking the regular UID. If sudo is not being used to run as root, instead just as a different user, then the user probably intended it.

Sounds good :) I found that python -c 'import os; print(os.getuid())' works consistently to get the user ID; since bootstrap.py is already in python I think you can check this just with os.getuid() == 0 rather than looking at SUDO_USER at all.

So should I remove the environment variable check and change this line to check if os.getuid() == 0 instead?

[gimbling-away]

Update: @chbaker0 you should be able to use sudo for accessing other users while running x.py now. Pushing soon 🎉

[chbaker0]

Thank you! I appreciate this a lot!

[Mark-Simulacrum]

Can you adjust the PR description to reflect the new state of this PR, and squash commits? r=me with that done.

@rustbot author

[gimbling-away]

Updated the description and squashed the commits.

[gimbling-away]

@bors r=Mark-Simulacrum

[bors]

@gimbles: 🔑 Insufficient privileges: Not in reviewers

[gimbling-away]

Welp I think I'm..doing something wrong here.

@Mark-Simulacrum So just manually pinging you 😅

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 386ca6a has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 386ca6a with merge 51d0df67856c2fe572c864cdef875437d90ef94b...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

The job x86_64-msvc-cargo failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

test workspaces::ws_warn_unused ... ok

failures:

---- registry::update_multiple_packages_http stdout ----
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe fetch -Zhttp-registry`
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe update -pa -pb -Zhttp-registry`
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe update -pb -pc -Zhttp-registry`
thread 'registry::update_multiple_packages_http' panicked at '
test failed running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe update -pb -pc -Zhttp-registry`
error: process exited with code 101 (expected 0)

--- stderr
--- stderr
    Updating `dummy-registry` index
error: failed to get `b` as a dependency of package `foo v0.5.0 (D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\tmp\cit\t1866\foo)`
Caused by:
Caused by:
  failed to query replaced source registry `crates-io`
Caused by:
Caused by:
  download of 1/b failed
Caused by:
Caused by:
  [1] Unsupported protocol (Received HTTP/0.9 when not allowed)
', src\tools\cargo\tests\testsuite\registry.rs:1634:10

failures:
    registry::update_multiple_packages_http

[fee1-dead]

@bors retry spurious