On Thu, 2011-11-03 at 12:25 +0100, Markus Weiss wrote: > So it looks like openconnect cannot change the user. Hm, interesting. Is it running as root to start with? I'm not sure why it wouldn't be able to setuid() in that case. And if it was already running as 'user' then it would even have tried to change; it would skip the setuid() call. > It looks like openconnect cannot change the user the usual way on > Meego/Harmattan. If i set the csd-user to root, the vpn server sends a > csd troian horse for i386 architecture, that the N9 cannot run. > How can I deal with this ? Do I need a wrapper script ? > Can anyone advise me, how such a wrapper would have to look like ? Your diagnosis seems correct ? it's giving you an i386-specific 'trojan'. The first thing to check is that this actually works OK on a desktop Linux box. Then you have two options. One is to install qemu-i386 and some i386 libraries, so you can actually run i386 ELF executables on the N9. That's quite a lot of overhead, but might be relatively simple to set up. The better option is probably to work out what the trojan is doing, and write a 'wrapper' of your own which emulates it. A year or two ago, there was some discussion on the mailing list about what the CSD trojan does; ISTR it usually downloads an XML file which describes a bunch of tests for it to run, and its result is a simple text string POSTed back to the 'csd_starturl' location. You could probably get away with using a 'wrapper' which just uses curl to post the expected answer to the appropriate URL, having watched it on a desktop box to see what it's doing. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5818 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111103/c58cd3bd/attachment.bin>
