need to run as root

[sunnysideup]

Issue Description

I was notified about update. I downloaded update It asked to install update I run it.

ERROR:

need to run as root:

SHELL=/bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer

Steps to reproduce

see above. I am on Ubuntu 20.04

Expected result

that root is not required or that I can set root to run.

[KhaledOmara]

+1

in my case when I'm trying to run: sudo /bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer I got: /usr/bin/pkexec: /usr/bin/pkexec: cannot execute binary file

[andyrichardson]

Hey folks, out of curiosity, is there a reason you're still using this?

This package has been deprecated since Atom added official repositories for all major linux distributions in 2017 (check the top of the README).

If there's a good reason for still needing this, I can look at helping you get this fixed.

[sunnysideup]

I just like to be on the latest atom - always... daz all, but I can update by hand. Which I do.

[demmerichs]

@andyrichardson I would be also still interested in this. It worked so well in the past. Also the official repositories are not updated with the same speed. E.g. right now sudo apt install atom shows me atom is already the newest version (1.48.0) whereas your package showed me the past days that version 1.49 was available, and now even 1.50 already. And as @sunnysideup mentioned, it is more convenient.

FYI: I have exactly the same problem/error stack trace as sunnysideup posted in the original query.

[andyrichardson]

Okay it sounds like there is some value in keeping this working - thanks for the feedback 👍

I'm off for the next week but would be happy to merge a PR if anyone can find the cause. My guess is the formatting for the download URL has changed (see here)

[demmerichs]

Okay, I took a quick look just now, however must say, I have never actually developed an Atom package or written in javascript yet. Am a python developer, mostly. So take my findings with a grain of salt. But I am happy to work on a PR if you could give me a hint now and then, because I have limited amount of time.

1. I looked at the URL and it still seems correct. In fact, when your tool asks the user to download, the download works and the file /tmp/atom-updater-linux.installer exists and can be used for installation.
2. The error message in Atom is: pkexec must be setuid root. However, like @KhaledOmara mentioned, if I execute /bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer (without sudo) I get the error cannot execute binary file. That bash is needed for the shell-call is probably something java/typescript specific (I do not know how the "SHELL=..." works). So I executed without the /bin/bash in front (pkexec dpkg -i /tmp/atom-updater/linux.installer): and it worked. pkexec managed to open up a password prompt window (because of course every installation needs sudo rights). I entered the password and the installation went its way. I stopped now, because atom is now actually updated and the package does not trigger anymore :D So I wait till version 1.51 which will hopefully be out when I am back from vacation in two weeks.

[andyrichardson]

Thanks for the investigation @DavidS3141 - I think you're onto something here.

if I execute /bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer

I assume you meant SHELL=/bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer right?

Not totally sure why the shell was explicitly declared but we can try omitting that or setting the environment variable like this.

  public install(): void {
    const cmd = `pkexec ${
      Config.installCmd[this.packageType]
    } ${Config.downloadFile}`;

    exec(cmd, { env: { SHELL: "/bin/bash" } }, err => {
      this.deletePackage();

      if (err) {
        return Notifier.installFailed(err.toString());
      }

      return Notifier.installComplete();
    });
  }

[demmerichs]

I assume you meant SHELL=/bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer right?

Sorry, no. I did not recognize kind of bash cmd, so I read it like SHELL=[cmd] and assumed that SHELL= was part of typescript specific syntax. How does a shell interpret a command like SHELL=some_shell cmd? I could not find anything on the web regarding this syntax. Or was there perhaps a semicolon missing:

~$ FOO="hi" echo $FOO

~$ FOO="hi"; echo $FOO
hi

On a sidenote: Why does there seem so much code doubled, in .js and .ts. Is *.js generated from *.ts?

[andyrichardson]

How does a shell interpret a command like SHELL=some_shell cmd? I could not find anything on the web regarding this syntax.

Here's a decent explanation

On a sidenote: Why does there seem so much code doubled, in .js and .ts. Is *.js generated from *.ts?

TypeScript (for now) is a precompiled language so it needs to be converted to JS before it can be used.

[demmerichs]

Ok, sorry for the extremly sporadic activity here :D Hope you still read this.

I had again some time to work on this and I find it still very weird. If I execute SHELL=/bin/bash pkexec dpkg -i /tmp/atom-updater-linux.installer everything still works, with the SHELL=/bin/bash being optional. In the package, there is child_process_1.exec which calls this exact same line, and it does not matter if with or without the leading SHELL=... or if i set the SHELL env option of .exec(cmd, options) explicitly, all returns still the same error: pkexec must be setuid root.

I explicitly changed pkexec to /usr/bin/pkexec to make sure I and the child_process use the same executable. I also checked the result of cmd=id from my terminal and from within child_process_1, and they also both give the same user back (me). And a google search with pkexec must be setuid root does not yield anything useful for me.

As I have no clue about npm and typescript I suspect there is something peculier going on with child_process which I am not aware off. @andyrichardson Do you have any idea here, that could result in these discrepancies?

[andyrichardson]

Ok, sorry for the extremly sporadic activity here :D

Story of my life - don't worry about it!

Do you have any idea here, that could result in these discrepancies?

In all honesty, I'm not too sure what's going on. From what I've seen online, it sounds like this issue might be system specific (maybe permission issues).

My next step would be to spin up a VM running Ubuntu and see if we can reproduce the error in a fresh environment.