Open Bug 1324744 Opened 3 years ago Updated 5 months ago
one click loaner has user root for the shell and user worker for the interactive display- not very easy to hack around
I got a one click loaner for a linux64 debug bc7 task, and after selecting option 2, I had to do a few things: 1) ~/workspace/build/tests was set as root, I switched it to worker so I could edit and hack 2) After 30 minutes of hacking around I am not able to get |mach mochitest browser/base/content/test/general/browser_addCertException.js| to work
Thanks for filing, this reminded me that there was another similar bug on file. I believe they are the same issue so duping to that one. There is a workaround in comment 1. As for the root issue, that's expected. Since you run in the interactive loaner as root, any files that get create (like the tests folder) belong to root. However, you said you weren't able to edit those files? That's another bug then, as you should already be running as root so should be able to modify anything :/
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1312739
should I file a new bug for the interactive desktop being logged in as worker while the files are unpacked as root, or should we use this bug?
I guess we can re-use this.. though it would probably belong under the Taskcluster product somewhere. Fwiw, I am unable to reproduce the root issue.
the confusion is: 1) get a shell and setup with the wizard. this downloads and unpacks things as user/group 'root' 2) open up an interactive display to run the tests, find out that we are logged in as 'worker' and cannot edit files, su has no clear path due to needing a pwd.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: one click loaner doesn't work well for |mach mochitest <path>| → one click loaner has user root for the shell and user worker for the interactive display- not very easy to hack around
Thanks makes sense. Jonas, could we login to the interactive display as root? Alternatively, we could run the wizard as the worker user.. but this seems a bit hacky and might cause other problems.
Component: General → Tools
Product: Testing → Taskcluster
The interactive display doesn't "run as" anything -- it just provides access to the X session. I suspect that running that X session as root will cause a lot of test failures. Everything (including the wizard) should run as the worker user. Early on in the task startup, we chown some things to root and then drop root privileges. The wizard should follow suit.
Component: Tools → Task Configuration
The wizard just runs with whatever privileges the 'taskcluster-interactive-shell' script has, which I believe is called from somewhere in the tools repo: https://dxr.mozilla.org/mozilla-central/source/testing/docker/desktop1604-test/taskcluster-interactive-shell It's also a nice feature that developers are able to install whatever packages/tools they need into the loaners, I think we'd want to keep that ability.
so then we could chown the files after setup?
The wizard could potentially add a line to /etc/sudoers to allow open sudo in that case, before dropping privs.
How to approach this bug: get a one-click loaner and experiment with the shell access. Based on comments above, think about ways to make that more user-friendly, then implement that.
Hi, can I work on this bug?
@evavranici let's focus on the other bug I assigned to you earlier, for now. There aren't a lot of open bugs available, so I'd like to make sure they are shared fairly.
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #12) > @evavranici let's focus on the other bug I assigned to you earlier, for now. > There aren't a lot of open bugs available, so I'd like to make sure they are > shared fairly. Sure.
This was made worse by bug 1323302, because if you now try to run the tests from the interactive shell, they fail with "Running Firefox Nightly as root in a regular user's session is not supported". What I had to do is 4 (exit), then `su - worker`, and `run-wizard` again.
(I also had to chown -R worker ~worker)
Flags: needinfo?(jmaher) → needinfo?(coop)
You need to log in before you can comment on or make changes to this bug.