Shuttleworth: Unity on Wayland [LWN.net]

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 3:30 UTC (Fri) by davide.del.vento (guest, #59196) [Link]

Mmmm. not so much. Yes, there are some web apps like CUPS config (which ironically I always needed only locally), and there are things that can be done in "reverse" compared to how they are done now.

But there will still be the need for "normal" X-forwarding via ssh, so a distro that completely kills it will be a deal breaker for me.

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 7:09 UTC (Fri) by rqosa (subscriber, #24136) [Link] (10 responses)

The way that Web apps are now (usually), they have a big deficiency in comparison to console or X apps running over SSH: when you use the console/X app, it runs with your UID, but when you use the Web app, it runs with the same UID as it does for everyone else. This is bad for security; it's as though every app were a setuid app.

Apache's "mod_suexec" is one solution to this problem, but its limitations (it can only run CGI apps, and it chooses which UID to run as according to the directory where the program resides) make it rather impractical.

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 12:51 UTC (Fri) by alankila (guest, #47141) [Link] (9 responses)

Webapps actually have far more interesting issue than the one you talk about. The most important problem is that all end-user data generally is accessible from the same server-side UID, as the guy who logs in a web application isn't using a distinct UID on the server side. The data is in fact usually written in SQL storage and there are no explicit security tags that the database server could check on behalf of the application: thus all data is available to every query, at least in principle.

Thus, all security features must be implemented through other kind of checking, often manually by comparing the user id on the database row being requested with the user id currently logged in. Not everyone remembers to do this all the time, though: generally a missing check for things like "is this user to authorized to view that page" results in information disclosure bugs.

I think a lot of real-world systems don't run a ton of webapps within one server and one uid. I personally tend to isolate running webapps inside virtual machines and use reverse proxying techniques to expose them where I want them. Virtual machines can be backed up and recreated wherever I want, so they are actually quite convenient to move as black boxes from a system administrator's perspective...

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 14:03 UTC (Fri) by rqosa (subscriber, #24136) [Link] (7 responses)

> Webapps actually have far more interesting issue than the one you talk about. The most important problem is that all end-user data generally is accessible from the same server-side UID, as the guy who logs in a web application isn't using a distinct UID on the server side.

Uh, that is the issue I'm talking about. Or at least it's a consequence of it (because the app always runs as the same UID, all of its stored data is accessible to that UID).

> The data is in fact usually written in SQL storage

But, the grandparent post was talking about, essentially, using a Web browser & Web apps to do what we formerly did/still do with an X server & remote X clients. That is to say, to take the kind of apps which now are X clients (e.g. image editor, email user agent, text editor, office suite, RSS feed reader, terminal emulator, XMPP client, etc.) and make them into Web apps. These don't usually use SQL; or if they do, they use a per-user database instance, e.g. an SQLite file owned by the user, or a per-user instance of mysqld (IIRC, KDE's "Akonadi" does this).

There's no good reason for these apps to suddenly become dependent on a central RDBMS server, just because they have migrated from one remote-user-interface protocol (X Window System) to another one (HTTP + HTML5 + JavaScript + whatever)!

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 14:51 UTC (Fri) by alankila (guest, #47141) [Link] (6 responses)

Hm. Well, suexec does nothing to solve that problem as far as I know, so I concluded that you must be talking about separating webapps from each other, not separating the users within a webapp from each other.

Otherwise I am in agreement.

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 17:07 UTC (Fri) by rqosa (subscriber, #24136) [Link] (5 responses)

> suexec does nothing to solve that problem as far as I know

Well, with suexec, the UID a CGI program runs as is determined by what directory it's in. A typical usage scenario is that each user has a "home" (or "public_html") directory (that is, a directory found at a path like "~user/public_html" or something similar on the machine where Apache runs, which Apache then exposes to HTTP clients as the URL "http://hostname/~user/") which may contain CGI programs, and when one of those program is executed, suexec will set the UID for its process to the UID of the user who owns the "home" directory it's in. (Or maybe it just picks the UID that owns the program file; I don't remember which way it is, but it doesn't make much difference.)

So, basically, suexec will separate webapps that "belong" to one user from webapps that "belong" to other users. Now, if you take one CGI program and make multiple copies of it, each belonging to a different user (that is, each in a different user's Apache home dir), then the different users of that app are separated from each other. But that is an ugly kludge, necessary only because of the limitations of suexec. So suexec isn't a good solution for this problem.

(Also, suexec is only compatible with CGI programs. CGI has its own problems, the biggest of which is that it requires every webapp process to exit immediately when it finishes generating a response message; that is really bad for performance. There are much better IPC protocols for webapps, such as SCGI, AJP, and FastCGI.)

Here's a suggestion: for "single-user" webapps, the UID to run the app as should be determined by the user specified in the HTTP request, with HTTP authentication (basic or digest).

Look at mod_wsgi...

Posted Nov 5, 2010 21:13 UTC (Fri) by Pc5Y9sbv (guest, #41328) [Link]

For Python web apps, you can use mod_wsgi which can use daemon processes under different UIDs to run different apps. It uses Unix domain sockets between httpd and the app daemon and runs many requests through one daemon instance, so you don't have the overhead of suexec on every web request. With a bit of work, this model ought to be portable to any app language, not made Python-specific, just by standardizing the unix domain socket protocol used for the request proxying. The mod_wsgi module is written in C, and I suspect would be a reasonable starting point if you gutted its embedded Python runtime (used when apps are not split into separate daemon processes), and instead made a separate daemon process stub that contained the app language runtime.

I've frequently considered that it would be nice to have a generalized mod_wsgi like this, and a user-mapping variant that could manage a daemon process pool with each authenticated web user getting his own app instance, which can be reused for many requests and shut down automatically when idle for too long. There is already some basic pool management in mod_wsgi, but it needs more features.

However, other aspects of the security model need to be matured, as web frameworks have such an in-built idea of one app for all users. You'd really need to make all of your server side resources now owned by the individual web users, e.g. good user/group models for files and good multi-role policies for your RDBMS.

Shuttleworth: Unity on Wayland

Posted Nov 6, 2010 11:33 UTC (Sat) by alankila (guest, #47141) [Link] (3 responses)

Um. The model of using CGI programs run by a central apache from user's home directory is probably not in the future. It would make slightly more sense to enable browsers to execute applications without a web server by emulating some common protocols such as fastcgi so that the application could be run without exposing it on any URL, even if that URL was just locally visible.

I don't think anybody is going to actually do desktop apps in the web browser. The most important feature of a web application is probably still the fact that it's accessible anywhere and requires no installation from user's viewpoint. A local application implemented as web app is only available locally and needs to be installed, so that advantage is wholly gone.

Shuttleworth: Unity on Wayland

Posted Nov 7, 2010 0:36 UTC (Sun) by rqosa (subscriber, #24136) [Link] (2 responses)

> The model of using CGI programs run by a central apache from user's home directory is probably not in the future.

Indeed, it isn't.

Here's how it should be instead: When person goes to use a remote app, they point their browser at the URL for the host where that app resides and the pathname on that host where the app is installed; for example "http://hostname/bin/my_app.py". Then, the user enters their authentication credentials (use HTTP digest or basic authentication for this) for that remote host. Then, any subsequent HTTP requests from that user will be forwarded (by SCGI or AJP or similar) to an instance of that app running as that user's UID. So, the Web app is installed in just one location, but there will be multiple running instances of the app, one instance per user. (Think about what happens with, for example, a host running an SSH server where many user log in via SSH and then run various console apps and X apps. It's the same principle: apps are installed system-wide, and there's a separate running instance of each app for each user using the app.)

> enable browsers to execute applications without a web server

I think this is already possible. (If you've got the Python documentation installed, try going to "/usr/share/doc/python/html/index.html" in a browser, type something in the search box, and press "Go".) But I wasn't talking about running web applications locally.

> I don't think anybody is going to actually do desktop apps in the web browser.

The trouble is, some people here are saying that we don't need X Window System anymore, because we don't need X's network-transparency anymore, because we have a better way to use apps remotely: Web apps. But, with X, most apps that you can run locally (image editor, text editor, etc.) you can also run remotely, and lots of people use this feature. That won't be possible if those apps migrate to a non-networked UI system (e.g. Wayland).

If we're really going to adopt HTTP + HTML5 + (whatever else) as the replacement for remote X, we've got to have these same kinds of apps available for it!

Shuttleworth: Unity on Wayland

Posted Nov 7, 2010 0:38 UTC (Sun) by rqosa (subscriber, #24136) [Link]

s/requests from that user/requests from that user to that URL/

Shuttleworth: Unity on Wayland

Posted Nov 9, 2010 0:29 UTC (Tue) by alankila (guest, #47141) [Link]

Hm. Okay, I start to see the point of the argument. I do have some severe skepticism that we'll rewrite gimp as web application anytime soon, though. I rather expect that something similar to RDP/VNC or yet-to-be-defined networking protocol will be used to take remote connections to wayland applications.

The most popular X-forwarded application I use personally is xterm and that's mostly because I'm too lazy to open local terminals and use separate ssh connections for them. If I had to choose between X-style vs. VNC-style, I guess I actually prefer VNC-style remoting because of the ability to leave the session running perpetually on the server. Unfortunately, in practice, VNC is not really such a stellar protocol, and I've seen RDP between 2 Windows systems perform better than VNC seems able to, for some reason.

Shuttleworth: Unity on Wayland

Posted Nov 6, 2010 5:44 UTC (Sat) by butlerm (subscriber, #13312) [Link]

The data is in fact usually written in SQL storage and there are no explicit security tags that the database server could check on behalf of the application: thus all data is available to every query, at least in principle.

There are good ways to fix that problem, namely "virtual private databases". You can implement them in any database that has update-able views that can filter on session variables.

I have an application that sets the database session state to match the application session when handling each page request. Until that state is set, all the "tables" return zero rows. After it is set, all the virtual tables contain only the rows the user is allowed to have access to, only those rows can be updated, and the application can only insert rows into the same range. Near perfect isolation. Any kind of attack can only affect the data of the logged in user.

Shuttleworth: Unity on Wayland

Posted Nov 5, 2010 19:46 UTC (Fri) by misiu_mp (guest, #41936) [Link]

Of cource you can ssh with vnc also, just tunnel the right ports, like that:
ssh -L 5902:localhost:5901