Great work! This is a nice package. Out of interest, did you find the unshare hack necessary for Debian? Last test I did on Debian (4.18 kernel but pre-2.28 glibc), Pulse seemed to work OK without interference. (AV mock not withstanding).
... View more
Couple of comments that my previous post wasn't a very clear solution, which I concede. Here's a clarification. If you're struggling to get Pulse Secure 9.0R1/2, working on Ubuntu 18.04.2 or 18.10 and it seems to crash while logging in, one of the known problems seems to involve the host checker reading and interpretting the OS process table. Confirm if the problem is indeed that by looking at the pulsesvc.log file: [email protected]:~$ grep -i cookie ~/.pulse_secure/pulse/pulsesvc.log
20190225102052.533212 pulsesvc[p7584.t7584] pulseui.error Failed to read return cookie from host checker process (pulseUi.cpp:1003)
If you get this output, it's likely you have this problem. You can temporarily relieve the situation by starting up Pulse in a slightly more contained environment where it can't see other processes. Doing so, of course, frustrates the host checker, so then you might need to fake things slightly. In my case, I need to run the Cylance AV checker: You can do it like this: 1/ Make a fake process for the Host Checker to find: [email protected]:~$ sudo ln -s /bin/cat /usr/local/bin/cylancesvc
2/ Modify your .desktop file so it looks like this (replacing USERNAME with your own): #!/usr/bin/env xdg-open
Exec=sudo unshare -f -m -p --mount-proc sudo -u USERNAME sh -c '/usr/local/pulse/pulseUi | /usr/local/bin/cylancesvc'
Comment=Pulse Secure VPN client
The desktop file Exec directive uses the Linux unshare command to start up a new process in a contained environment. The options provided isolate the process table (what you see with ps) and the mount points. You need to kill the mount points because /proc will show the original situation, which seems to be the cause of the Pulse secure crash on login. The --mount-proc option creates a fresh /proc environment based on the new restricted process environment. Then you use sudo to run, as yourself, a pipeline containing the Pulse GUI connected to the fake Host Check process. This is just a simple way to start two processes, where one of them is a dummy to be found by the other. (You should obviously continue to run the main app required by Host Checker as normal and stipulated by your IT folks). For this to work, sudo to execute things without a password challenge, which you may or may not be happy with. Your /etc/sudoers file would look like this: %sudo ALL=(ALL:ALL) NOPASSWD: ALL I haven't really diagnosed nor understood quite why Pulse Secure crashes when reading the process table, and I can't spot many differences between, say, a vanilla 18.04 process table and an 18.04.2 setup. As some have suggested the kernel has changed, as has the runtime C library, so it may be a problem there somewhere. But this workaround might give struggling users somewhere to go, and it might also give the Pulse Secure developers a couple of pointers on where the problem lies so that they can correct this in the long-term.
... View more
Ubuntu 18.04.2 desktop edition here, using 4.18 linsux kernel (yes, I've noticed that 18.04.2 server editions seem to run 4.15. No clue why there is a difference) and 9.0R2-819: [email protected]:~$ uname -a Linux macbookpro 4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux My Pulse Secure client doesn't work. I noticed that it was crapping out reading the process table at the behest of my VPN concentrator implementing the Host Checks. (In my case looking for the presence of an AV process). Sure enough the process table on my 4.18 box versus a 4.15 box does slightly differ in the names of the early kworker process titles. It was using libc 2.28's fnmatch to match process names, but I'm not quite clear on why it was crashing. Anyway, I discovered that you can insulate it from whatever the moody input is using the linsux namespace system calls, which were a bit of a dark art to me, but useful all the same. Here's what works for me: # Start a shell as running as my username, but isolate the process table # and mount points. You need to do the latter because /proc gives the # game away otherwise - you need a fresh one. [email protected]:~$ sudo unshare -f -m -p --mount-proc sudo -s -u adamc # Examine process and be surprised at result. Eek, no other pids: [email protected]:~$ ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 72720 4164 pts/1 S 20:58 0:00 sudo -s -u adamc adamc 2 0.1 0.0 29568 4540 pts/1 S 20:58 0:00 /bin/bash adamc 10 0.0 0.0 44480 3352 pts/1 R+ 20:58 0:00 ps auxww # Start up any processes that Host Checker looks for (link to /bin/cat - cough!) [email protected]:~$ /usr/local/bin/cylancesvc & # Start up the Pulse GUI and login as usual. [email protected]:~$ /usr/local/pulse/pulseUi & This pattern seems to work reliably for me. Though it's not perfect. If I disconnect uncleanly (say by just killing the GUI and not disconnecting), the isolated VPN client seems to leave something system-wide that prevents subsequent connections. Perhaps it helps some struggling with this?
... View more