mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #475] Barrier fails to launch on Catalina due to Security and Privacy permissions #368
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#368
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mandusm on GitHub (Oct 21, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/475
Operating Systems
Server: OSX Catalina 10.15 (19A583)
Barrier Version
2.3.2
Steps to reproduce bug
shapp.Other info
Upgraded to Catalina
Not that I have found
Yes
@mandusm commented on GitHub (Oct 21, 2019):
Related to #474
@technovangelist commented on GitHub (Oct 23, 2019):
not sure if this is helpful or not, but I am not having an issue with Catalina. I don't remember doing anything special to get it to work after the upgrade.
@shadow1163 commented on GitHub (Oct 23, 2019):
On macOS 10.15 and barrier v2.3.2, it also work for me. But I also add "sh" to "accessibility". Hope is helpful.
@mandusm commented on GitHub (Oct 23, 2019):
Yeah, I am a little apprehensive to allow my shell
shfull control over my machine... So I would love to not have to do that...@mandusm commented on GitHub (Oct 23, 2019):
https://github.com/debauchee/barrier/issues/343#issuecomment-510147391
That comment seems to indicate that modifying the
Info.plistwill fix this issue...From
To
I have not tested this myself yet. If it works, I will update this issue.
@AdrianKoshka commented on GitHub (Oct 23, 2019):
The problem with that might be the fact that
barrieris only the GUI, and thatbarriercandbarriersare the client/server applications.@ctsrc commented on GitHub (Nov 7, 2019):
Being a former user of the upstream Synergy, I discovered Barrier today after I was having trouble with Synergy not being able to connect a new pair of client and server computers that I was configuring when using Bonjour/Zeroconf hostnames. The details of that are irrelevant here but just as I was about to open an issue about it in the upstream repo, I found a page on the Arch Linux wiki about Synergy that mentioned Barrier.
https://wiki.archlinux.org/index.php/synergy
That page said that whereas Synergy GUI will not let you enable encryption without a valid license, the Barrier GUI allows doing so. That's a huge deal IMO, so I decided to give Barrier a shot to see if it was able to connect my server and client using Bonjour/Zeroconf hostnames. And it was!
So anyway, the machine acting as host is running macOS High Sierra 10.13.6, and the machine acting as client is running macOS Catalina 10.15.1.
I set up the Barrier server on the High Sierra machine first and gave Accessibility permission to Barrier.
I went on to set up the Barrier client on the Catalina machine, and as noted in the comments of this issue, doing so requires giving the Accessibility permission to
shrather than to Barrier.As @mandusm points out, giving Accessibility permission to
shis problematic. The reason why it is problematic of course is because it means that any script or program executed byshwill be able to utilize these permissions. Furthermore, it also means that any other GUI applications utilizing a startup script would gain these privileges too. The purpose of the Security & Privacy controls in macOS is to limit what each individual program is able to do to your computer. It is therefore important that the permissions are handed out to each individual piece of software correctly.Furthermore, making it so that the Accessibility permission is given to Barrier rather than to
shwill provide a better user experience for both new users running on Catalina and for existing users who have upgraded their OS to Catalina from a previous version of macOS. In the case of the former, users will expect to see the name of the application for which permission is needed and in the case of the latter they will have the permission assigned already (but note that the latter would need to update Barrier to a version that fixes the issue of course).Looking at the contents of the
barrier.shscript, we see that all that the script does is to change its working directory to the script location and then executing thebarrierbinary from there.Now you might say that this is actually a problem with macOS Catalina and not with Barrier, and you might be right about that. After all, previous versions of macOS were able to identify the permission as being needed by the Barrier application specifically, even though the way it starts up is by running a shell script that it turns executes
barrier. It could also be that it is intentional on the part of Apple and that it is a necessary consequence of the changes that were introduced into the permissions model of macOS with the release of macOS Catalina.Either way, it is my opinion that with such a simple script it would be highly beneficial to just get rid of the script all together, by making the change mentioned by @mandusm above in https://github.com/debauchee/barrier/issues/475#issuecomment-545675538.
So the question then is, does
barrieractually need to start from that directory, or is it able to locate all the files that it needs regardless of which directory it is executed from? I suspect that it might in fact not need that, and that this might simply be an artifact of older versions of the software.Looking at https://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe, we see that handling this for all platforms would mean that quite a bit of additional code would be needed, but looking at the sources of Barrier, we also see that the shell script is created by the macOS specific build script
726f5e2b53/dist/macos/bundle/build_installer.sh.in (L60-L63)and therefore that regardless of what is being done on other platforms, we could removebarrier.shon macOS and add code that changes the working directory of thebarrierbinary specifically on macOS wrapped in#if defined(Q_OS_MAC)/#endif. But like I said, it seems that changing the working directory is not necessary at all, in which case we only need to removebarrier.shand changeInfo.plistin the way that @mandusm mentioned.I will try this on my two machines and report back shortly.
If this proposed change works on my machines I will open a PR for it, and I will want users of Barrier 2.3.2 running other versions of macOS to try it out and ensure that Barrier works the same way on those other versions of macOS as Barrier 2.3.2 does.
@ctsrc commented on GitHub (Nov 8, 2019):
Confirmed that the proposed solution works on macOS Catalina 10.15.1 and confirmed that it stills works as it should on macOS High Sierra 10.13.6 with the change applied. Submitted a PR with the fix.
@TheCire commented on GitHub (Nov 15, 2019):
Any news on when this will be released? This bug/issue is the only thing keeping me from upgrading to Catalina. Thanks =)
@StreetGuru commented on GitHub (Nov 17, 2019):
Not working for me - I've edited the Info.plist as suggested but it's still asking me for elevated permissions for sh every time i try to launch barrier.
Can you elaborate on your fix?
Apple is trying hard to loose customers - complicating security settings to a point where users are faced with dialogues to authorize programs that should never be authorized is a huge security risk as i suspect many people will not be knowledged enough to know what they are doing (or care) when all they want is their apps to work.
@StreetGuru commented on GitHub (Nov 17, 2019):
I got it working - though not sure exactly which of two actions did it:
After reading another thread about the same problem - https://discussions.apple.com/thread/1496021 - it was suggested to move or rename the bundle and move/rename it back so the info.plist edit took effect;
I also had to delete the app from the accessibility authorization - next time I launched barrier it asked me to authorize it again and it's finnally working.
@sheykh-sleky commented on GitHub (Nov 20, 2019):
Like @mandusm said for us Catalina (10.15.1) users; edit the Info.plist and remove the ".sh" then rename the app (I put a z in front of Bundle) then renamed it back to Bundle... Able to secure and launch.
Sadly - Scrolling doesn't work. But it does launch and it does move the mouse and clicks where I want it to.
@TheCire commented on GitHub (Nov 21, 2019):
I suppose my question is, when will this "fix" be integrated with the main branch and released as a binary? I always have bad luck doing things like this... I can almost never compile anything from source as I always get some issue. I would just like to see it "just work". Thanks.
@StreetGuru commented on GitHub (Nov 21, 2019):
You don't have to compile anything, it works very easily:
It will ask you to give accessibility permissions to barrier - do it and you're good to go.
edit: Changed 2. and 3. to make it clear that you can't edit the downloaded .dmg file but the barrier app inside.
@dee-see commented on GitHub (Dec 4, 2019):
@StreetGuru Thank you for these steps! Excuse the absolute mac-newbie question but the contents of the .dmg file are readonly and I'm wondering how I'm supposed to save the changes to the .plist file?
EDIT: Got it with the help of this https://myjeeva.com/best-possible-way-edit-read-only-dmg.html
@StreetGuru commented on GitHub (Dec 4, 2019):
@dee-see I'm guessing that you were trying to edit the barrier app within the downloaded dmg? You need to mount the dmg and extract the app to any folder (downloads or desktop, for example) and then edit the info.plist in there; after that you can move the barrier app to the Applications folder.
Glad you managed to sorted it out though.
@mandusm commented on GitHub (Jan 7, 2020):
A very simple fix to this is using your shell.
DMGfile from releases.DMGand copy theBarrier.appto yourDownloadsfolderterminalappApplicationsfolder.@rdewolff commented on GitHub (Mar 23, 2020):
Thanks @mandusm - that worked like a charm.
@DNNhost commented on GitHub (Mar 23, 2020):
“Barrier.app” is damaged and can’t be opened. You should move it to the Bin.
@rodneyrod commented on GitHub (Apr 6, 2020):
Just to add, you may need to remove Barrier from the Accessibility list in System Preferences, then open Barrier and allow it permission again before this method works.
@cbrookins commented on GitHub (Jun 23, 2020):
I went the @StreetGuru route. Worked nicely. This seems like a pretty big security issue, why has their been no release including this fix? A lot of users may not dig this deep to find a resolution, or even realize the security implications.
@shymega commented on GitHub (Jun 24, 2020):
@cbrookins Not much can be done until we have the funds to register our app with Apple for the signing, IIRC.
This is by no fault of Barrier - or the few developers.
@ctsrc commented on GitHub (Jun 25, 2020):
@cbrookins @shymega the problem in this issue was resolved in PR #487 which was merged on 10 Nov 2019, but there have been no releases since 3 Oct 2019. The Apple signing thing is a separate issue and not related to this one.
@shymega commented on GitHub (Jun 25, 2020):
Ah yeah. I must have been mixed up with the signing issue... release is on the cards, sorry for the delay!
@mgrant0 commented on GitHub (Jul 27, 2020):
I went to install Barrier 2.3.3 for first time on a mac using Catalina and I am up against the same problem.
"Barrier" cannot be opened because the developer cannot be verified.
I see that 2.3.3, the plist file has been modified and the .sh extension removed. I don't see Barrier in the Accessibility system preferences. I did try adding Barrier to the list of applications that could control my computer in the Security & Privacy section, but this did not help.
Anyone else get this working on macOS Catalina 10.15.5 or later?
@ctsrc commented on GitHub (Jul 27, 2020):
@mgrant0 sounds like what you are experiencing is related to signing and not to the issue that was originally being discussed here.
Try to right-click the app and select open. The security dialog that comes up then will allow you to open the app.
@mgrant0 commented on GitHub (Jul 27, 2020):
I agree, related to signing. I do not see that dialog that you speak of. I managed to run it from the termainal but I can't get back into the setting screen. Unless you have any quick ideas, I will post on a more appropriate thread. Thanks for your suggestion.
@ctsrc commented on GitHub (Jul 28, 2020):
@mgrant0
The dialog that you mentioned is like this right?
If instead of running the Barrier app directly, you navigate to the Applications directory (or wherever you put the Barrier app), and right click the Barrier app icon to bring up the context menu and select Open
Then you will instead get a dialog that looks like this:
And then you can click on the button in the dialog that says Open.
At this point you will probably be asked to give permission like so:
Once you've granted that permission:
Then after that, since you told the system that it was ok to run the application even though it is not signed, then you should be able to run Barrier normally.
When you then run Barrier, it might ask you to perform setup:
Once you are done with the setup you should then be seeing the main window of Barrier:
Let me know if this helps you run Barrier. And if you are still having trouble getting it to run, and decide to post a separate issue about it, then feel free to tag me in the issue so that I am notified of it and I will try to see if I can help you further.
@ctsrc commented on GitHub (Jul 28, 2020):
Also one more thing @mgrant0, when you try to right-click the Barrier icon in its location, make sure that you are doing it from somewhere on your drive, and not from within the DMG file itself. Because if you right-click and Open it from within the DMG file then you will just get the same message as the one that is seen when you attempt to run it directly.
So if you currently only have it inside of the DMG then you need to first open another Finder window and navigate to your Applications directory and drag the Barrier app over from the DMG to your Applications directory, and then right-click it there and select Open from the context menu.
@mgrant0 commented on GitHub (Jul 28, 2020):
Thanks for those very detailed instructions! I have had some success now, but I ended up starting it from the terminal yesterday before I saw your instructions. I have it up and running! But there's a couple odd things I've learned along the way.
If, after I start barrier and then exit (the red button) the config screen, there's no apparent way to get back to it.
I have 3 icons in the doc:
If I leave the Barrier settings window running, then, any 3 of the icons get me back into the settings icons. I sent the 2 on the right side to the bin. If not running, none of the 3 do anything when I open/double-click them. Upon reboot, when Barrier comes back (I have it set to start on login), the first one comes back when I open Barrier window and the second one comes back when I configure and reload to get it working as a client. So I am guessing that the right 2 icons are associated with the 2 barrier processes that are running.
If I do x out the settings window, the only way I have found to get it back is to go into a terminal window, find the Barrier processes running and kill both of them, then restart Barrier (or reboot).
I wonder if I did something wrong in running it like that at login time.
And by the way, yes, I absolutely am clicking on the Barrier app inside the Applications folder. And I did try what you wrote about trying to start it from the right-click menu on the icon in the Applications folder versus double clicking the icon, but now that I managed to get around this permission problem via terminal, I no longer see the popup. In Terminal, ls shows it as Barrier.app inside /Applications that I am clicking on in the finder.
The current small frustration I have at the moment is if I accidentally x out of the settings window, no amount of clicking or opening via menus will get me back to the settings.
@ctsrc commented on GitHub (Jul 28, 2020):
For the dock, I personally chose to disable showing recent items on my machine, because I never found that very useful. So if you don't use the recent items are for anything too then you might wish to do the same, by going to the macOS system preferences, and then Dock and then deselecting "Show recent applications in Dock".
Other than that I don't have any good idea for the multiple icons thing at the moment.
As for the x out of window thing, what you are seeing happening is that when you close the window, Barrier closes the window but it intentionally keeps running, so that one doesn't accidentally disconnect from another machine.
In the right side of the macOS menubar at the top of the screen, in the same group of tiny little icons where you see the WiFi symbol and those things, you will also see the Barrier icon when Barrier is running. And if you click that icon then you can bring back the Barrier main window after you've closed it by selecting "Show" from the menu.
Hope this helps
@mgrant0 commented on GitHub (Jul 28, 2020):
Ahh hah! Much better. I disabled the recents and found it as you said and now it makes much more sense. Thanks again!
@shymega commented on GitHub (Jul 28, 2020):
Its a real pain, yeah - with the signing. Hopefully we can raise some funds to get Barrier signed by Apple at some point... although I understand why they want people to sign though.
@dehesselle commented on GitHub (Oct 3, 2020):
@shymega I'm doing packaging work for another open source project and I can offer to sign/notarize the macOS release, if you are interested. (also for reference https://github.com/debauchee/barrier/issues/602)
@p12tic commented on GitHub (Jan 10, 2021):
@dehesselle Thanks a lot for the offer. Is it still valid?
@dehesselle commented on GitHub (Jan 11, 2021):
Yes, the offer still stands. The only catch is that I'll want to keep my account credentials to myself, i.e. I'm not comfortable with integrating them into CI. If you are looking for full automation, that might be a no-go for you.
@seanbperiod commented on GitHub (May 25, 2021):
Hey I just want to piggyback here - I have it running on Big Sur, but I'm greeted with "Do you want the application “Barrier.app” to accept incoming network connections?" everytime, even though the permission is already set in the firewall.
I've even tried removing it from the firewall and manually adding back, and the popup still occurs on startup.
However, regardless of the popup, it still runs in the background and automatically connects to the other computers..
Is there any way to remove this annoying message on startup?
@zoiec commented on GitHub (May 6, 2022):
I encountered this issue as well after upgrading to Monterey from Catalina
I installed Barrier 2.4.0 without issue on Catalina.. the only thing I had to do is create my own Barrier.pem file myself
Then I upgraded to Monterey... After the upgrade I tried to start Barrier and it would always ask me to grant it permissions in accessibility... Barrier was already checked
I tried unchecking it, restarting and then checking it after restart... still Barrier would not start
I checked my Info.plist file however that did not have Barrier.sh in it, so I left it alone
I was able to solve this issue by:
@emacstheviking commented on GitHub (May 11, 2022):
@zoiec Massive thanks! I just got an M1 macmini running Monterey and I have an older iMac from late 2012... I was getting very despondent until I tried your fix. Now I have perfect concert operation. Thank you !
On the older iMac I deleted then reinstalled the latest Barrier.app, mine was a few years old IIRC. On the macMini it all worked fine but I had to try several times to get things in the right order.
@bradleydworak commented on GitHub (Jun 28, 2022):
I also started to experience issues with Barrier failing to launch due to the Accessibility permission errors after upgrading macOS, even though Barrier was already listed as having granted Accessibility access. A straightforward option that worked on macOS Monterey was to begin by flushing out the current list items that were granted Accessibility using the following command
sudo tccutil reset Accessibility. Then, I manually added these items back, including Barrier. Thanks.@dJani97 commented on GitHub (Jan 23, 2023):
Barrier worked fine until the latest update on my M1 Air, and @zoiec's solution solved this issue for me. Thanks!