Konqi on Windows XP?
Wednesday, 9 July 2003 | Kpfeifle
Want to run Konqi from a Windows XP desktop? Want to use KDE's marvellous Quanta Plus Web editor from inside Windows? Not that you particularly like XP -- it's just that you have no choice. Well, with NX now you can. I've compiled some background info on how to achieve this, including some nice and revealing screenshots: Konqi on WinXP 1, Konqi on WinXP 2, Quanta on WinXP, KDE Session on WinXP.
KDE supporters of the "Office Productivity" booth at LinuxTag are preparing to show off this very cool application of remote X. It uses a new, highly efficient compression technology that allows one to run a full KDE session (or single application) remotely and display locally even over a 9600 baud modem link. A KDE startup may transfer as little as 35K across the wire, while a remote "vanilla" X session would use as much as 3.5M.
NoMachine are also trying to gain recognition in the "Guiness Book of World Records" by having more than 100 users concurrently connected to their application server, each running a full KDE desktop session with KOffice.
The server will be named "desktop.linuxtag.org" and will be officially online on Sunday 13th from 13:00 to 14:00, and also available for training and testing on Friday the 11th.
As an aside, running GNOME on this server is also possible. Perhaps there will be 50 GNOME/OpenOffice.org and 50 KDE/KOffice sessions in parallel, joining forces to win the record against Citrix MetaFrame... Stay tuned!
Comments:
Windows ? - Brazilian Boy - 2003-07-09
. What Mr. Gates thinks about this ?? 8-D This could be a great experience. I think this is the only way to crack your box and see the infamous "blue screen" when you are playing whit KDE. .
Bit of a misleading title - Rob Kaper - 2003-07-09
Running Konq from XP is nice, but the "on" word in the title is a bit misleading.. when a person skims the headers he/she could think this was a port or hack instead of a remote application server. This won't exactly help anyone to run KDE applications on XP with a dual boot machie. :) That said, cool initiative. I hope they win the contest. Does Nomachine support dialback? That's one of the most important features my dad's company requires for RAS (MS Word compability being the other in their field of work, unfortunately).
Re: Bit of an misleading title - Kurt Pfeifle - 2003-07-09
> the "on" word in the title is a bit misleading.. ...but the question mark remained (despite of the editing by Nav which changed a bit of the meaning... )
Re: Bit of an misleading title - Navindra Umanee - 2003-07-09
Hey, how do you know it was me? I'm not the only active editor on this site... :-) Actually it was in this case, and I added the "?" where there was none at all before. Sorry if I changed the meaning of anything, I was trying to make it clearer and concise and I'm guessing that in the process of removing ambiguity perhaps I introduced an error?
Marvelous Quanta Plus - Eric Laffoon - 2003-07-09
Wow! Now we're marvelous! I don't know how many people can relate... I just have my head buried pushing along thinking what I'd like Quanta+ to be and then I see it mentioned so often. Every time I still say to myself "Hey! That's my program! We've been noticed." I guess application wise I'd have to say we are really becoming a standout, but maybe the realization hasn't quite caught up to me. I'd like to say we look "mahvelous" but I noted a hideous typo and the top image is still squeezed and overlaps in this shot even at that screen size... Grrr! It never ends. And BTW seeing Quanta on XP is utterly weird for me as I run Linux only. No Machine looks like an incredible accomplishment. Then again so is KDE and XP users could use the upgrade. ;) Thanks Kurt for mentioning Quanta+... even though I did have to experience the shock of seeing it run on XP. :-O
Commercial X-Server - Anonymous - 2003-07-09
So this is a commercial pricy X-Server with free clients and compressed transmission (like compressed and encrypted SSH tunnel)? Why was this posted here!? As mentioned the story title is misleading and the only relation to KDE misses time zone information.
Re: Commercial X-Server - Aaron J. Seigo - 2003-07-09
i think the relevancy is due to the fact that they are using bits of KDE code (e.g. for their customized window manager thing) and apparently lean towards running KDE sessions themselves. as for why their software is interesting: it uses remarkably little bandwidth providing for high quality sessions even over the public Internet, it has management tools (including on the client side), supports several different OSes on the client-side with minimal hassle to set it up, supports RDP and X11 and provides security benefits such as no XDM, no non-NX logins, etc... since their licensing is per server rather than per user, their product is also quite cheap compared to other offerings in this same market. this is indeed a very interesting product and one that could help adoption of KDE in corporate settings.
They're using Kwin - Ale - 2003-07-12
That's why! =) And, yes it is awesome. Also, its not so pricey if you get the personal server and hey you can view your desktop everywhre even ona ps2!
Re: Commercial X-Server - Simon - 2003-07-09
I find it interesting, and the price is pretty attractive for business use.
Re: Commercial X-Server - Dik Takken - 2003-07-09
Did you all see they provide the source code under GPL licence? Seems like this technology can be integrated in the standard XFree86 distribution! Wow!
Re: Commercial X-Server - Kurt Pfeifle - 2003-07-09
> Seems like this technology can be integrated in the standard XFree86 distribution! Yes it can. It is all GPL. It is up to XFree86. Also, KDE has been invited to write its own frontend to the NX server and client technology (as have GNOME and LTSP).
Re: Commercial X-Server - Rich - 2003-07-09
Not if the source really is GPL. GPL'd stuff can't go into XFree86 mainstream due to license incompatibilites. A fork is possible however.
Re: Commercial X-Server - Kurt Pfeifle - 2003-07-09
All the core compression libraries developed by NoMachine are GPL. NoMachine doesnt use different and improved libraries for their commercial offering (unlike CrossOver). KDE has been invited to develop their own client frontend as well as the an NX-based server, with the help of NoMachine. The same invitation has been going out to GNOME and LTSP.
Re: Commercial X-Server - Anonymous - 2003-07-09
>>NoMachine doesnt use different and improved libraries for their commercial offering (unlike CrossOver). << Currently they do. The commercial version is at 1.2.2 (with many improvements, according to the release notes), the free version is 1.2.1.
Re: Commercial X-Server - Anonymous - 2003-07-09
(Which does not mean that it is bad or something, but they obviously also have a commercial interest)
Re: Commercial X-Server - Kurt Pfeifle - 2003-07-11
Version 1.2.2 has been released as source code too. There was a mishap which prevented the correct version to be displayed on the website. Actually the link named 1.2.1 pointed in fact to the download version 1.2.2. This is fixed now. Thanks for noticing.
Shameless... - Anonymous George - 2003-07-09
waste of resources making this work, if you ask me...
umm - ciasa - 2003-07-09
why is this news. I've been running konqi on xp for a while now just using cgywin. Its not that hard. Just modify the x startup with an option -noroot or something like that, then `konqueror&`
Waste of time - Debian User - 2003-07-09
People should run KDE on top of XP if at all. Doing it remote is no news at all. You can btw. just use cywin from Redhat on your XP and run KDE locally or use the X-Server to run it remote. Free and better mayhaps. Yours, Kay
Re: Waste of time - Kurt Pfeifle - 2003-07-09
> Doing it remote is no news at all. No it isnt, you are right. The news is the excellent compression technology. The news is that it runs even across a modem. The news is that we are running 100 KDE sessions in parallel on one server.
what's this?? - jb - 2003-07-09
What a ridicolous post! Running remote apps through X11 is nothing new, it was there before Linux and even before KDE. What NoMachine/NX does isn't described at all. There was some talk about NX technology on the XFree lists a while ago, which was quite interesting. At the time I thought it was some proxy technology. Sounds like a hard business idea since X11 is being phased out since it is very picky on network latency as compared to RFB and other simple stuff (Sun used something similar on their Rays). Their technology may be good if they have cured this problem, but how many will really use it? Now it sounds like NX is some commercial X server which is an even worse idea. There are already XFree on Windows. The market for proprietary ones is tougher than ever. And remember what's a server in an X11 network -- that's right, the terminal! That really kills thin computing with expensive X servers. I would hope NoMachine turns out to be good guys and helps the X people design a much better protocol for X12 and making it fully multimedia capable. Would this be hoping too much? It'd be great if someone from NoMachine could tell their side of the story here ...
Re: what's this?? - Kurt Pfeifle - 2003-07-09
> What NoMachine/NX does isn't described at all. It is not described in detail. It does compression, it does caching, it does encryption, it does differential transfers and it uses a proxy on both sides (client and server) > I would hope NoMachine turns out to be good guys and helps the X people design a much better protocol for X12 and making it fully multimedia capable. Would this be hoping too much? No, the hope is valid. NoMachine have donated all their core library code under the GPL. (They *could* have used a different license...) KDE and GNOME are invited to use the libraries to develop their own, competing (and Free) alternative.
Re: what's this?? - Rich - 2003-07-09
To be honest I'm terribly pleased about this. It appears that the XServer for Windows is basically based on the XFree86/Cygwin sources [based solely on the presence of cygwin1.dll] but takes up a lot less space than a minimal Cygwin install. At my university the public workstations (Novell/Win2k based) only have a crapola XServer (Exceed) and having this small Xserver that fits in my homespace is excellent. The Xserver itself is totally compatible with plain-old X over SSH. Combined with PuTTY (or even some hacking of the client software) it provides an excellent, small, replacement for my previous Remote Access solution.
Re: what's this?? - Anonymous - 2003-07-09
Are you sure that the source of the server has been released by NM? Cannot find it (and they are not required to, it's not GPL).
Great :) - Niek - 2003-07-09
This is really great :o I tried the NoMachine TestDrive server: great performance on a slow connection. I think I'm going to set up a trial personal server at home, this is way and way much better than vnc. I would really love it if krfb (http://www.tjansen.de/krfb/) would get NX support. From what I understand, at least the client support is possible with the GPLed NX libs. And what about server support? Are those libs also GPLed? Greetings, Niek.
Re: Great :) - Tim Jansen - 2003-07-09
- Desktop Sharing Server support for a protocol that is not bitmap-based would be a huge amount of work and require large changes in the X11 server. - AFAICS the sources for the NX server (which does not share the screen but creates new X11 sessions BTW) have not been released, only the client. My current plan for the client is to add support for plain X11 over ssh first, and later for NX's nxproxy compression and their improved Xnest variant. This construct will not be able to connect to the NX servers directly (which I don't really care about, since there is only a proprietary implementation), but it will be able to connect to every system that has the NX server installed. But plans can change, especially since I am not done with looking through the NX code and the documentation is pretty.. well, non-existent.
NX is great but they aren't the first... - Daniel Arnold - 2003-07-09
When I read the article I remembered that I once read about a similar solution for running X11 compressed over a small bandwith connection. So I searched and found two (completely free and older) projects: The first DXPC (Differential X Protocol Compressor) seems to be more similar to NX (or NX to DXPC ;) ?): http://www.vigor.nu/dxpc/ The second one LBX-Proxy is a part of XFree86: http://ftp.xfree86.org/pub/X.Org/pub/R6.6/lbxproxy/ A small comparison between both (and an explanation of LBX-Proxy) can be found at the end of an old HOWTO (last updated 1997) I found at The Linux Documentation Project: http://www.tldp.org/HOWTO/mini/LBX.html So I think a side by side comparison (compression rates etc.) between all three would be quite interesting. Of course NX seems to go much beyond the to other projects since it also can compress VNC, integrating sound etc. Perhapes it would be the best to take the free available compression libraries from NX combining them with one of the projects above and make a free NX-compatible solution. And perhapes integrating this solution in Krfb would be easier and more attractive since it is a completely free solution then.
Re: NX is great but they aren't the first... - Tim Jansen - 2003-07-09
NX's origin is DXPC, it seems to be based on the mlview-dxpc variant. The old mlview site also forwards to www.nomachine.org now. LBX is not really comparable, NX does much more.
Re: NX is great but they aren't the first... - Daniel Arnold - 2003-07-10
I searched quite a while the net to find a copy of mlview-dxpc since almost all links refer to the now forwarded (to nomachine) mlview-dxpc page. The last version I could find was v0.159-MS1 (from march of 2001): http://freshmeat.net/projects/mlview-dxpc Direct download link: http://freshmeat.net/redir/mlview-dxpc/13579/url_tgz/mlview-dxpc-v0.159-MS1.tar.gz A project also concerning with streaming sound over dxpc can be found at the end of: http://www.edu.uni-klu.ac.at/~mkropfbe/xray.html By the way does anybody know a good ftp (or Archie) search engine in the rank of Google)? I miss the days of AskSina. :-(
Re: NX is great but they aren't the first... - Anonymous - 2003-07-10
www.filewatcher.org ?
Re: NX is great but they aren't the first... - Daniel Arnold - 2003-07-10
The above mentioned URL http://www.edu.uni-klu.ac.at/~mkropfbe/xray.html provides much more as I thought. It seems to be a further project called X-Ray (now also comercial) with the same goals as NX. In his master thesis ( http://www.edu.uni-klu.ac.at/~mkropfbe/papers/X-Ray_thesis.ps.gz ) you can get a detailed analysis of the current solutions (VNC, etc) and a detailed description of his X11-based solution and much more (like ideas and solutions to sound and video forwarding). I think this paper can be much valuable for building up a free NX(-like) solution. He also forked Xnest and called this new programm Xray (which he released with sources to ne net according to his paper) and compressed the stream over mlview-dxpc. Unluckily he has removed the program xray from the net (but says on his page that you can write him a mail if you are interested) and I couldn't find the sources or binaries anywhere. :-(
Re: NX is great but they aren't the first... - Tim Jansen - 2003-07-10
The difference between Xray and NX seems to be that Xray has persistent sessions. So when you disconnect from Xray the session does not end automatically, but you can reconnect later. This is also possible with, but not with NX. The NX guys seem to work on it though.
Re: NX is great but they aren't the first... - Kurt Pfeifle - 2003-07-11
mlview was indeed the predecessor of NX. NX has the same lead programmer as mlview....
open source - Mark Hannessen - 2003-07-09
only parts of the client where released open source. ( and the client was already free as in beer ) if i would have to guess then this is a tactical move. make your ( already free ) client open source and hope it gets into as many distro's as possible and then... gain popularity.. and money !!! but hey... that's just my conspiricy theory.
Re: open source - Tim Jansen - 2003-07-09
The most important parts, the nxcomp library and nxagent, have been released. What they did not release is their servers and clients (there is a compatible command line client now though). This is a somewhat strange situation, since this almost forces free software developers to create an incompatible implementation based on their technology. AFAICS I can not write a krdc backend for NX without some changes in the server (because I need to embed the remote window). While at the same time my motivation for writing a client for their protocol is pretty low, since I can't use it anyway. And their protocol is also pretty bad for systems without NX which may be understandable (they want to sell servers, they don't care for systems without NX) but also makes me work on an alternative solution.
Re: open source - Datschge - 2003-07-10
This post by an NX employee makes an OSS based NX-ifying progress of any X server without buying their complete solution sound very easy: http://www.xfree86.org/pipermail/forum/2003-March/000667.html
Re: open source - Tim Jansen - 2003-07-10
Creating a new solution that uses their compression technology is easy. But then you can not use their server (which is also responsible for things like coordinating users, managing samba and so on).
Re: open source - Datschge - 2003-07-10
Quote by Gian two post above the one I posted before: "> What other stuff have you developed to be included in NX that is not under GPL? The top level software. Everything you can do with NX Client and NX Server can be done by hand, using OSS components. We count on users being lazy." I see now what you mean. Nevertheless would it be possible to start with a comparatively little subset of the features offered by NX? Since Krfb as of now doesn't include many of NX's features anyway just ignoring them as for now wouldn't be a problem for current Krfb users while they still can make use of the main advantage of NX, vastly improved screen performance over slow connections.
Re: open source - Tim Jansen - 2003-07-10
Not krfb (the server), because that will only work with bitmap-oriented protocols like VNC. But it is possible to add X11 with NX compression as additional backend to krdc (the client). krdc will then create a new session when you connect.
Re: open source - Kurt Pfeifle - 2003-07-11
> But then you can not use their server Huh? What do you mean to express by this? "Use" their server by accessing it from a Free client should be possible. Write a Free server which is accessible by a Free client as well as the NX client should also be possible. They say that there might be further developments, and that the version 2.0 might break the backward compatibility to 1.x.x. protocol and compression, but they are intending to also document and release it to.... I have no reason to not trust them on this....
Re: open source - Tim Jansen - 2003-07-11
It is possible to write a client that talks to their server, but, as you said, then I would have to implement a free server. Which would be a lot of work and also a lot of reverse engineering, since there doesn't seem to be a clearly defined protocol. At least for unix-systems there are simpler solutions, and I also have a few issues with their architecture (from what I understand after staring at their code for a few hours, correct me if I am wrong): - they currently seem to create a special user called 'nx' on the ssh server. If you login with that user (no password, uses only a DSA key that's part of nxclient, so everybody knows it) via ssh you enter a special shell that allows you to do the real login. This requires a lot of trust in sshd and the nx server, much more than with a direct authentication of the user via ssh. Everybody can log in on your computer and access the NX shell. And the shell probably runs as root or has root-like privileges, as it can login other users. because they use their own authentication mechanism, plain text password or MD5 over encrypted ssh connections, it is not possible to use other ssh authentication mechanisms like Kerberos. Plain text passwords and MD5 hashes require that you fully trust the server you log in or use a separate password for each computer. This is quite bad for many remote administration use cases when you want to connect to computers that you don't fully trust, like many desktop machines and especially notebooks - it only works when you have the NX server installed on the system. A system that would use a plain ssh login could use fallback options that work even on systems without NX They obviously have reasons to do it this way: the server should also work on non-Unix systems like Windows. The alternative architecture that I tend to implement works a little bit like fish. Login via ssh, install a perl/shell script on the server and start it. The script would examine the environment, check which DEs (KDE, maybe Gnome) are available, whether NX libraries are installed and so on. It sends this information via STDIN to the client, which may let the user specify options, and after that the script starts nxagent or Xnest with the selected DE. Beside backward compatibility, security and better authentication this has the advantage that it is more realistic for KDE 3.2.
Re: open source - Gian Filippo Pinzari - 2003-07-12
> Everybody can log in on your computer and access > the NX shell. And the shell probably runs as root or > has root-like privileges, as it can login other users. nxserver, that's the nx shell, doesn't run with root privileges and you don't have any way to break in as root if not by knowing the root password. A per-server NX private key is created at the time the NX server is installed. The public nx user doesn't need to run as root as it logs to the node (usually the same machine where NX server is running) using the public key. The public key is "trusted" by all the NX-enabled users on the server. By breaking into the nxserver as user "nx", you can eventually run a shell as any user that is NX-enabled. On the other hand, this doesn't give in any case root access to the machine and let you just run as an unprivileged user. By the way, nxserver will never allow you to run sessions as user root. > because they use their own authentication mechanism, > plain text password or MD5 over encrypted ssh > connections, it is not possible to use other ssh > authentication mechanisms like Kerberos. We don't -presently- support other authentication mechanisms. This doesn't mean that is "not possible" to implement alternative methods and maintain compatibility with the default one. Infact this is what we plan to do. > Plain text passwords and MD5 hashes require that > you fully trust the server you log in or use a > separate password for each computer. A NX login offers the same security offered by SSH. If the key of the server is changed, user is warned and the connection is aborted. Obviously you presently need to have a separate password for each computer, that's not that bad in 99% of the cases. Future versions will be able to offer single sign-on logins, Kerberos and authentication based on smart cards. This will be treated as an option, as requires that the NX user that logs in to a machine is the same real user that runs the session. This is not what we want in all the cases, as we need to support "guest" or "anonymous" sessions, the way is possible with HTTP. > The alternative architecture that I tend to implement > works a little bit like fish. Login via ssh, install > a perl/shell script on the server and start it. I don't see much differences, except that you run everything as the "real" user. So you cannot manage the running sessions, the processes, the mounts and the other sysrtem resources except if you run something else as root (that I wouldn't consider more secure) or otherwise implement a mechanism to have a "limited privileges" user, like the nx user, that can access someone else's accounts. This is exactly what we do. > that it is more realistic for KDE 3.2. May you please explain this point better? I was at the KDE booth at LinuxTag, together with other NX developers, both today and yesterday. I spoke with Andreas Pour and others. I looked for you, as I was told you were at LinuxTag. I think the best is that, if you like, we sit down and have a chance to exchange some opinions. This will save a lot of time spent on "reverse engineering" things that are not really intended to remain obscure. /Gian Filippo Pinzari.
Re: open source - Tim Jansen - 2003-07-12
> nxserver, that's the nx shell, doesn't run with root > privileges and you don't have any way to break in as > root if not by knowing the root password. But how can it log-in users with knowing only the MD5 hash of the password? You need at least some setuid component. > A per-server NX private key is created at the time the > NX server is installed. How does that help? It will allow the server to authenticate to the users (which is also important, especially with plain text passwords), but what prevents somebody who does not know a valid account from getting through the sshd login process and accessing the nxserver shell? My issue is that a user without credentials can do relatively complex operations with sshd and also nxserver, which would require a much higher level of trust in both sshd and nxserver than a regular ssh login. > Obviously you presently need to have a separate password for each computer, > that's not that bad in 99% of the cases. Hmm.. you are probably thinking about different use cases than I do. One of my major use cases is an administrator managing workstations, with a (NX) server running on each. > I don't see much differences, except that you run everything as the "real" user. So you cannot > manage the running sessions, the processes, the mounts and the other sysrtem resources > except if you run something else as root (that I wouldn't consider more secure) or otherwise > implement a mechanism to have a "limited privileges" user, like the nx user, that can access > someone else's accounts. If the authenticated user would be able to access a server via unix domain sockets or a similar mechanism it can do the same things (on Unix systems, as I said for Windows/Cross-platform that would be more complicated). The difference is that the amount of code that you need to trust would be much lower, and you would get all ssh authentication mechanisms, including password challenge-response, public key authentication and kerberos, for free. I see this feature as something that should be possible by default on every single desktop machine, including desktops. Any potential vulnerability should be avoided, and the ssh login is perfect because it does not increase the risk. > > that it is more realistic for KDE 3.2. > May you please explain this point better? Time constraints. I have quite a lot of work to do for 3.2, and the direct login mechanism would be the easiest (because fish makes it really easy to execute commands on remote machines, I just need to write a GUI and scripts for the server-side). But that would not exclude the possibility of adding support for the NX server as well, there's just not much time. > I was at the KDE booth at LinuxTag, together with other NX developers, both today and > yesterday. I spoke with Andreas Pour and others. I looked for you, as I was told you were at > LinuxTag. Sorry, I only visited LT today.
Re: open source - Gian Filippo Pinzari - 2003-07-13
> But how can it log-in users with knowing only the MD5 > hash of the password? You need at least some setuid > component. I tried to explain this in the previous post. Sorry if I was unclear. NX server sets the nx user's public key in the trusted keys of the added account, so, once the real user is authenticated, nx user logs to the node without the need to use the real system password. This doesn't prevent NX to client and server to use a different authentication method, infact we already have a preliminary version that just relies on SSH daemon and logs users with any method supported by SSH. In this case, anyway, nxserver is still executed as user nx, as this (unprivileged) user is the one that has control of resources assigned to running sessions. > How does that help? [...], but what prevents somebody > who does not know a valid account from getting through > the sshd login process and accessing the nxserver shell? Nothing. Is this a problem? What prevents a user to run a httpd process on a Apache web server? It just a matter of writing a secure nxserver (the way you need a secure SSHD or HTTP or IRC or FTP or whatever server). > My issue is that a user without credentials can do > relatively complex operations with sshd and also > nxserver Sorry, I don't understand this. It executes nxserver. What nxserver does is to check the password by means of any of the supported mechanisms (MD5 password or any auth method supported by SSHD+PAM) and if login fails it exits. It's exectly the same you get by running HTTP (as user nobody) over SSL. > Hmm.. you are probably thinking about different use > cases than I do. One of my major use cases is an administrator > managing workstations, with a (NX) server running on each. I think at the millions users of any Linux computer anywhere in the world. The case somebody sets up up a single-logon domain is not that widespread. On the other hand there is no problem to handle this with current architecture. You just ignore a feature (the possibility to have separation between system accounts and NX accounts) to use another feature (the possibility to identify any system user as a NX user). > and you would get all ssh authentication mechanisms, > including password challenge-response, public key > authentication and kerberos, for free. As I explained, the only difference is that NX server does much more han what you prospect and we need to run services as nx user if we want to control the server machine without running monitors and daemons as root. > Time constraints. I have quite a lot of work to do for > 3.2, and the direct login mechanism would be the easiest > [...]. But that would not exclude the possibility of > adding support for the NX server as well [...]. I think that your plan is absolutely OK and I agree that we can have better interoperability in future :-). I just wanted to make clear some technical details. Please don't hesitate to write to me if you have any question or any issue to discuss. /Gian Filippo Pinzari.
Re: open source - Tim Jansen - 2003-07-13
>>but what prevents somebody >> who does not know a valid account from getting through >> the sshd login process and accessing the nxserver shell? > Nothing. Is this a problem? What prevents a user to run > a httpd process on a Apache web server? It just a matter > of writing a secure nxserver. Yes, but that's why newer distributions do not enable httpd by default anymore. To reduce the amount of network-accessible functionality that may contain security leaks. BTW it is not only about nxserver, also sshd. When sshd has an exploit that can only be used by authenticated users, the attacker would gain root rights. The initial authentication is only a subset of sshd, so allowing untrusted users to authenticate increases the risk. Not a significant risk for a server which also runs services like httpd and which can be assumed to be administered by someone who will update when there are exploits etc. But quite a risk for a desktop machine run by a casual user. > As I explained, the only difference is that NX server does > much more han what you prospect and we need to run services > as nx user if we want to control the server machine without > running monitors and daemons as root. On Unix you could have the same capabilities when users would login using ssh and then start a setuid executable that runs as the nx user.
Re: open source - Gian Filippo Pinzari - 2003-07-14
> But quite a risk for a desktop machine run by a casual user. I agree that running SSHD on a computer can be considered a security risk, but we are still speaking about enabling remote logins to a desktop machine. As an experienced Unix user, I would tend to trust SSHD more than a new login daemon written from scratch. > start a setuid executable that runs as the nx user This is what we do when using SSHD/PAM auth methods. In this case you end up trusting the user even more as, for example, you cannot force a logged NX user to run a restricted shell. Furthermore, this still doesn't solve the problem of having guest logins.
Re: open source - vivek - 2004-04-01
sir iwant to know how much linux security is full proof. can some one login the server as root without changing the root password. if so then please tell me all the means and preventives also. vivek.
Re: open source - Kurt Pfeifle - 2003-07-11
No conspiration theory needed. NoMachine spelled out in public what their intention is and how they imagine to make a living from their development. Any person with the willingness and power to read it may find it f.e. here: http://lists.kde.org/?l=kde-promo&m=104889637120424&w=2
This isn't anything new. - SupetPET Troll - 2003-07-14
There have been commercial X-Servers for windows for a long time. At my univ (Univ of Minnesota) I did exactly this on Win2K. I had/have debian at home with KDE3 on it. I would use the x server that the univ had on its windows machines and run KMail from home. It was fairly slow even though I have a 1.5/384 ASDL at home and the univ has something <b>FAR</b> better than that, but usable. Here is what I would do. Run the non-commercial SSH client at school to SSH to my home debian machine -- with X tunneling on. Then I would run the xwin server on the univ's win2k machine. Then I would go back to the ssh client at run what ever like kmail and about a 30-45sec later a window would open up and then another 15sec or so it woul finish drawing the window and I could use kmail. Those times were also highly dependent on which kde theme and icons I was using.
commercial ML-View - Anonymous - 2003-07-15
After reading the NoMachine pages and seeing that they are based in Italy, it suddenly all came clear to me.. These are the guys that made ML-View which was influenced by dxpc ( http://www.vigor.nu/dxpc/ ), which itself was influenced by LBX. It sure would have been simpler if they just said that NX is an X-protocol compressor! Just wondering if this also does session management, like the SUNray or X-Ray ( http://www.edu.uni-klu.ac.at/~mkropfbe/xray.html ) ?!
Re: commercial ML-View - Datschge - 2003-07-15
Uh, they do say that.