Page MenuHomePhabricator

mw update could fail if the directory the binary located is not writable
Open, LowPublic

Description

I had mw v0.5.0 as /usr/bin/mw and tried to update by executing mw update but failed.

$ mw version -v 2
mw version 0.5.0 ( 2021-10-17T22:25:22Z )
https://gitlab.wikimedia.org/releng/cli/-/releases
GitCommit: e47f25b
GitBranch: HEAD
GitState: dirty
GitSummary: v0.5.0-dirty
BuildDate: 2021-10-17T22:25:22Z
Version: 0.5.0

$ mw update -v 2
New update found: 0.6.0
? Do you want to update? Yes
12:49:40 Uncompression is not needed https://gitlab.wikimedia.org/api/v4/projects/16/packages/generic/mwcli/v0.6.0/mw_v0.6.0_linux_amd64
12:49:40 Will update /usr/bin/mw to the latest downloaded from https://gitlab.wikimedia.org/api/v4/projects/16/packages/generic/mwcli/v0.6.0/mw_v0.6.0_linux_amd64
Binary update failedopen /usr/bin/.mw.new: permission denied

while sudo mw update has succeeded.

Event Timeline

It seems to be related to https://github.com/inconshreveable/go-update/issues/46 and the library has not been updated for five years.

I started looking into this a bit, and turns out its a bit of a pain.
I can't figure out how to detect if the current executable file can be written to by the present user, as the only way I can see to do that in go is to open the file for a write, which currently results in open /tmp/mw: text file busy
Best I could do is check if the directory is writable? Which might be enough? maybe?

Addshore moved this task from Inbox to In Progress on the mwcli board.

I made half baked attempt here that at least might catch this issue most of the time.

https://gitlab.wikimedia.org/releng/cli/-/merge_requests/106

@Lens0021 if you have the ability to build that and try it out I'd love to know what you think!

Nah, I don't like this at all, or the files in it D: I think a better approach would indeed be to try and catch any weird non writable errors

Feel free to move to In Progress if you still are working on this task, Thank you!

Not looking at it right now!