The culprit could be that you extracted snowflake to a location that does not support the same type file permissions (shared folder device running another type fs) then copied it from there. Try moving the tarball to the GW first then extracting there?
Source:
It seems snowflake-client still cannot be executed by debian-tor user. Here is the full operations:
Here is the original permission and ownership of snowflake-client:
user@host:~$ ls -l snowflake-client
-rwx------ 1 user user 14160744 Jun 4 06:17 snowflake-client
It can be executed by user user:
user@host:~$ sudo -u user ./snowflake-client
2018/06/04 06:18:21
--- Starting Snowflake Client ---
2018/06/04 06:18:21 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:18:21 Waiting for a "signal" pipe...
^C
We now change the permission to let it executable by user debian-tor:
user@host:~$ sudo chmod 777 snowflake-client
user@host:~$ sudo -u debian-tor ./snowflake-client
2018/06/04 06:18:43
Noticed the permission denied:
--- Starting Snowflake Client ---
2018/06/04 06:18:43 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:18:43 Waiting for a "signal" pipe...
2018/06/04 06:18:43 open signal: permission denied
We now change its ownership to debian-tor:debian-tor:
user@host:~$ sudo chown debian-tor:debian-tor snowflake-client
user@host:~$ ls -l snowflake-client
-rwxrwxrwx 1 debian-tor debian-tor 14160744 Jun 4 06:17 snowflake-client
Still, permission denied:
user@host:~$ sudo -u debian-tor ./snowflake-client
2018/06/04 06:19:15
--- Starting Snowflake Client ---
2018/06/04 06:19:15 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:19:15 Waiting for a "signal" pipe...
2018/06/04 06:19:15 open signal: permission denied
However, when executing it by user, it works fine:
user@host:~$ sudo -u user ./snowflake-client
2018/06/04 06:19:22
--- Starting Snowflake Client ---
2018/06/04 06:19:22 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:19:22 Waiting for a "signal" pipe...
^Cbetter don’t change permissions of singular files. Then the executed
file cannot look at related files.
chown --recursive debian-tor:debian-tor /path/to/folderThank you for telling me this! 
I tried to extract the tar after sending it to the targeted gateway and then do the chown -R on the entire TBB folder. It still does not work with debian-tor user.
Still permission denied errors?
Perhaps snowflake wants to write into ~/ home, which then wouldn’t be possible. There is no debian-tor home folder (not usual to have home folders for system users) and as for user’s home folder, there would be permission denied.
Can snowflake data dire be specified on command line or in config somehow?
Idea… In a non-Whonix test VM… Put a whole home folder under git control. Add all files to git. Start snowflake. Stop snowflake. Use git status to see what files are new or modified.
For testing only.
sudo mkdir /home/debian-tor
sudo chown -R debian-tor:debian-tor /home/debian-tor
sudo su debian-tor
(In final version we could not use /home/debian-tor. snowflake-client would have to be a in a proper location and access rights sorted out.)
Tested on both Debian-9 and Whonix-14-Gateway.
I suspected that the issue is related to systemd.
Here are the steps on Whonix-14-Gateway:
First, write confs below to /usr/local/etc/torrc.d/50_user.conf:
DisableNetwork 0
UseBridges 1
ClientTransportPlugin snowflake exec /home/user/snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -max 3
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72
Then do systemctl restart tor and it will complain permission denied.
Now let’s see what systemd really executed:
user@host:~$ grep "ExecStart=" /lib/systemd/system/tor@default.service
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
We executed the command ourselves with sudo:
sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
And yes, there will be no complain about “permission denied” and Tor will successfully connect to the Tor network (it may take a little bit time).
This indicates systemd does not necessarily work as sudo command-in-the-execstart-section.
To do further investigation into the problem, I need to learn more about how systemd really works.
Any thoughts on this?
Yes, any of the following, apparmor or seccomp is likely the cause.
cat /lib/systemd/system/tor@default.service
apparmor:
# Hardening
AppArmorProfile=system_tor
seccomp:
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
CAP_DAC_OVERRIDE
Thank you so much for your instructions, @Patrick !
As you pointed out, the problem turns out to be a common apparmor issue which has been fixed by:
For Qubes-Whonix, it can be tested as follows:
First, open Whonix-Gateway Template, and write the line below to /etc/apparmor.d/local/system_tor and shutdown the template:
/usr/bin/snowflake-client rix,
Second, open an AppVM that is based on it, and extract the snowflake-client executable from the latest experimental TBB to /usr/bin:
sudo install -o debian-tor -g debian-tor -m 700 snowflake-client /usr/bin/
Third, restart Tor with:
systemctl restart tor
Now, Tor is using snowflake in Whonix-Gateway!
Whoops, I forgot to say the torrc file in AppVM should look like this:
user@host:~$ cat /usr/local/etc/torrc.d/50_user.conf
UseBridges 1
ClientTransportPlugin snowflake exec /usr/bin/snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -max 3
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72Next tasks:
There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :
snowfalke-client executable.Doesn’t work for users under censorship?
Great question!
All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor can’t connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?
If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:
Done:
Once we get snowflake-client into Whonix-Gateway, I will merge this branch into master branch. 
//cc @HulaHoop
iry:
Great question!
All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor can’t connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?
That’s it.
If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:
It’s possible.
We could do gpg verification, we have such code in tb-updater which
could be made into tpo-downloader but very messy:
iry:
- Whonix distributes the executable ourselves
- pros: more controls by Whonix and it should be more stable
- cons: trust issue, a lot of extra work for Whonix developer
We could handle it “same way we handle Tor Browser default installation
in Whonix-Workstation”.
It would require (major work…):
transforming tb-updater into tb-downloader (just a better name, no
actual separate development step, just conceptual for explanation) since
it’s really a downloader, not updater (doesn’t persist user settings
like TBB internal updater)
transforming tb-downloader into tpo-downloader
installing tpo-downloader by default on Whonix-Gateway
download, verify, extract snowflake during the build of Whonix (like
tb-updater currently does for Tor Browser on Whonix-Workstation)
Minor (details, easy):
making the Tor Browser Downloader (by Whonix developers) launcher
invisible on Whonix-Gateway using config-package-dev displace (easy
since I did it before many times, existing code examples in Whonix code,
I can handle)
making the snowflake Downloader (by Whonix developers) launcher
invisible on Whonix-Workstation using config-package-dev displace (easy
since I did it before many times, existing code examples in Whonix code,
I can handle)
iry:
There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :
- Wait until snowflake-client gets into Debian: Make a deb of snowflake and get into Debian (#19409) · Issues · Legacy / Trac · GitLab
- pros: Whonix developers only need to include snow-flake and future maintenance cost is nearly zero.
- cons: Needs someone to make it into Debain, considering the fate of meek, this may never happen.
This is the very very best solution.
Even snowflake available von deb.torproject.org would be better than anything below which is very hacky, very maintenance intense long time.
“considering the fate of meek, this may never happen.” - Why? How is snowflake being blocked by meek?
- Use a script to download the latest experimental TBB in Whonix-Gateway and extracted the
snowfalke-clientexecutable.
- pros: the script will be simple
Not simple unless file hashes are hardcoded since gpg verification automation done right is hard.
- cons: need to figure out how to run the script regularly, a lot of maintenance work
Yes.
- note: it seems these are not blockers at least in the case of snowflake: https://phabricator.whonix.org/T118 and make TBB usable as "system Tor" (#14121) · Issues · Legacy / Trac · GitLab
Correct.
I was thinking that meek never got into Debian because of the lack of manpower and cooperation. Will snowflake suffer from the same fate that it keeps waiting for someone to get it into Debian?
I agree. Here are the 4 ways to distribute snowflake binary: