humbug / phar-updater

A thing to make PHAR self-updates easy and secure
BSD 3-Clause "New" or "Revised" License
368 stars 27 forks source link

Checking hasUpdate() should not require is_writable for phar file. #20

Open jxn opened 7 years ago

jxn commented 7 years ago

I would like unprivileged system users, who do not have the ability to run self-update commands, to be able to check if an update for the command is available. Currently, the following results in an exception:

        $updater = new Updater(null, false);

        $updater->getStrategy()->setPharUrl($updateDomain . '/app/current.phar');
        $updater->getStrategy()->setVersionUrl($updateDomain . '/app/current.version');

        try {
            $result = $updater->hasUpdate();
            if ($result) {
                echo "update available";
            } else {
                echo "update NOT available";
            }

Here's the exception of the local phar file is not writable:

[Humbug\SelfUpdate\Exception\FilesystemException]
The current phar file is not writeable and cannot be replaced: /usr/bin/bobafetch.

I think the new Updater() is checking for writability... but writing shouldn't be required to check for updates.

aik099 commented 7 years ago

What would be a use case for this?

jxn commented 7 years ago

This comes up often for me with scripts which are globally installed.

For instance, we deploy a phar automatically to /usr/bin/myscript which is used by users across the system. Most of the users use the phar, but only one should be allowed to update it. In the event of a failure when an unprivileged user uses the phar, she should be able to see if the phar is up to date, and request that the administrator update it.

Ideally, we would be able to institute a check when users run other commands, which would use phar-updater to check if the latest version is in use. Then, when a user ran myscript some:command, they would be warned that "myscript" is not up-to-date. Currently, that would throw an error and prevent all unprivileged users from running any command.

Additionally, we have scripts that do integrity checks on systems. These scripts should not be able to write to the system, but it would be nice if they could check if globally-installed phar files are up-to-date and report that to system administrators.

jxn commented 7 years ago

I have added this in PR #21

aik099 commented 7 years ago

In the event of a failure when an unprivileged user uses the phar, she should be able to see if the phar is up to date, and request that the administrator update it.

That's what I imagined myself. But on the other hand isn't it's administrator job to ensure all stuff is up to date and not forward that task on regular user 😄

Then, when a user ran myscript some:command, they would be warned that "myscript" is not up-to-date. Currently, that would throw an error and prevent all unprivileged users from running any command.

I'd like that, but again this could be an option because displaying your app is out of date message to user that can't really update it adds more confusion. In your case I admit it can be useful.

Can you please also attach an exception trace?

padraic commented 7 years ago

I've been AWOL for a while, but I'll doing a round of PR reviews eventually. I see no harm in this change myself if it's useful.

tschach commented 6 years ago

Hi, what is the status of this? I came across the issue using a third-party application that includes phar-updater. If someone could give me some pointers, I would be willing to help solving this issue. Best, Tobias