Capabilities of Dreamhost PS / Vserver: setuid, chroot, etc

software development


As I described in another, I want to have different web services on my sites run as different users - but I want them to be within the same domain. E.g. I want and to be run, suxec’ed or the equivalent, as different users foo and bar.

Since Dreamhost does not allow this for normal shared hosting (different user are associated with different subdomains, not different directories in same domain), I am considering using Dreamhost PS / Linux Vserver (or going somewhere else, like GoDaddy or EC2).

So, I have some questions about Dreamhost PS / Linux Vserver:

a) does it give me the right to have setuid cgi scripts? (Even if I have root in the Vserver, if the filesystems are NFS with no-setuid, I will not be able to effect this.)

b) can I configure Apache to suexec to different user IDs within the Vserver guest? Heck, can I configure Apache at all, or is that done outside the Vserver?

c) can I configure multiple hostnames to share the same fixed IP?

d) in the above, can I supply my own certificates, multisite, wildcard, self-signed or otherwise?

e) can I chroot inside my Vserver?

(I don't think so, but I hope I am wrong: Vserver builds on chroot, and I think they take the chroot capability away inside the Vserver gues.)

All of these questions amount to "Yeah, I may have root inside the dreamhost Ps / Vserver guest, but what things is this root not allowed to do? setuid? chroot? administer apache?

I have signed up to test a Dreamhost PS / Linux Vserver, but I thought that I would ask these questions, since it may avoid some headbanging.


I’m afraid this simply isn’t possible to do with Apache. The Apache SuexecUserGroup directive can only be applied on the virtual host level — it cannot be applied on a directory-by-directory basis.

I’ll continue with the rest of your questions, though:

Yes. All newly created DreamHost PS guests are on local storage with no unusual mount options, so setuid will work just fine.

Yes, subject to the mod_suexec caveat I mentioned above. The configuration file for your Apache instance is in /dh/apache2/apache2-hostname/etc/httpd.conf.

Yes. Our automated management doesn’t currently let you do this, but there’s nothing keeping you from disabling management for your Apache instance and messing around with the configuration yourself.

Yes. I’m pretty sure that SNI doesn’t work yet, though, so all virtual hosts sharing an IP must share the same certificate. (If you’ve got a wildcard certificate, you’re in luck.)

Yes, chroot works fine within VServer guests.


Thanks fo the reply.

It’s strange that Apache does not seem to support suexec on a per directory basis. I could swear that I configured this - a long time ago, when suexec was relatively new.

But, if setuid works, great. Except… setuid doesn’t seem to be working. Nevertheless, since you say it should, I’ll bang on it some more. Seuid done properly is more flexible than suexc (although also easier to get wrong).

Thanks again for the quick reply.[hr]
Hmmm… --suexec-userdir

Maybe that’s what I remember, although placing ~ in the pathnames will be ugly:

I wonder if mod rewrite will allow me to eliminate the ~ ugliness.[hr]
Looks like mod_rewrite does what I wanted and half remembered, as follows:

Content Handling

From Old to New (intern)

Assume we have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. Actually we want that users of the old URL even not recognize that the pages was renamed.
We rewrite the old URL to the new one internally via the following rule:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo.html$ bar.html

I.e. I can rewrite to,
without the new URL showing up in the location bar.

Downside: the user can access, which is ugly, and might become legacy.

Downside: if my user names were as long as my subdirectory names, no problem; but given UNIX username limits, problem. Will have to rewrite to
Ugly, but better than to, and having to remember that user00 corresponds to semipublic-wiki.


Still no sure about setuid vs suexec.

Still haven’t gotten setuid working.

Sometimes I use setgid rather than setuid, to make editing the scripts from a non-cgi user master account easier.


setuid working.

needed to install suid-perl

thanks. now I need to decide which of the several techniques to use to create isolation



(1) it should be easy enough to make the --suexec-userdir functionality available, on a user by user basis, via Apache

(2) it should be straightforward to add this to the Web Panel “manage users” interface. I imagine some click box saying “make net.accessible?”

 (Q: is this web panel management interface open source?  I may do a patch.)

(3) providing --suexc-userdir as well as SuexecUserGroup has at least one advantage:

I keep getting the wrong user ID asociated with my subdomains. [Bad consequence #1]: the user name that I really, really want to not be associated with any of my websites happens to be alphabetically first, and is always selected by default, not only when I set up a site, but also when I am editing sites. [Bad Consequence #2]: I end up with multiple sites with the same user name, losing isolation.

If the username mapping is viable in the URL, it’s hard NOT to know exactly what username the site or subsite is running as. Reduces the chance of me making a mistake. (Although it has the consequent badness of allowing the world to see.)


I’m at home right now so I can’t check any of the details right now, but here’s a quick rundown:

suexec-userdir kind of works if you set it up manually, but it requires you to be using mod_userdir, which is hardly optimal. You can try to rewrite around it, but chances are the ~username path chunk will show up when you least want it, especially when you get your own mod_rewrite rules involved. Also, since it’ll only run scripts out of ~/public_html, you’ll have to go through all sorts of contortions to run multiple sites off of the same user.

Basically, you’re trying to do something that we don’t really support, mostly because there’s very little demand for it. Quite honestly, you may be better off just setting up multiple hostnames to get the privilege separation you’re after.

(The web panel is not open-source. Sorry. It’s kind of our “secret sauce”.)


You’re probably right. I’ve spent way too much time on this.

As I explained earlier, one of my motivations is to be able to share the same SSL cert between CGI scripts of different privileges. More specifically, the same unique IP. I’m $$$ challenged, so paying for a unique IP for each privilege is beyond my budget.

I’m one f those old fashioned UNIX security people who think that efery site should run as a separate user.

Heck, if I could I would have separate users within mediawiki, for read-only and read-write access.

And it’s pretty good as web panels go.


Just thought I would record a note here wrt something I figured out, in case (1) somebody else wants to do the same thing, or (2) heck, I might forget and need reminding.

My goal: I want to have more than one unix user ID running CGI scripts within the same virtual host. In particular, within the same virtual host with a unique IP, allowing it to use an SSL cert - i.e. two different unix user IDs, same SSL cert.

Standard dreamhost does not allow this. Suexec allows only one unix user ID per virtual host / subdomain. Dreamhost does not allow setuid on the NFS filesystems of normal shared hosting. Although DH allows multiple unix user IDs, it does not enabled userdir by default. Which means, as far as I can tell, that in Dreamhost’s shared hosting setup you can (a) use multiple UNIX user IDs in different hosts, with separate unique IP and SSL certificates for each of them, paying roughlly 43$ for each unique IP, or (b) you can save money, and use only a single unique IP and cert, but then you lose the security of having different web services running as different unix user IDs, or © you can use different unix user IDs in different subdomains, but then you don’t get SSL.

I think that both separate unix user IDs and SSL matter. But, since I am currently developing my personal use sites - I want the UNIX user Ids to isolate test cgi scripts from “production” - I can’'t afford to pay for extra unique IPs.

(In particular, I think that every mediawiiki site needs SSL - you type passwords in).

So, here’s what I have done:

I’ve signed up for Dreamhost PS, Linux Vserver.

(I know: I could have had several unique IPs for the cost.)

This gives me root in a box, the ability to administer Apache, and the ability to run setuid CGI.

As you can see above, I’m thrashing on whether to use Apache userdir or setuid, or something else.

I’d prefer not to modify dreamhost’s configuration at all, or at least not much. Userdir seems to require modifications to Apache httpd.conf.

I’m not sure how to arrange to share a single unique IP amongst multiple hosts, but I’m guessing it would require similar httpd.conf modifications.

I just got setuid cgi working. I am ashamed to admit I got stumped here for a while. I could see that setuid was working from an interactive shell, but failing from the web. Apache’s suexec log was saying that it was encountering setuid/setgi, but not saying that was unacceptable. But it was.

So, I had to invoke the setuid cgi scripts indirectly, not from suexec itself, but from the script suexec started.

I haven’t decided if I prefer to use setuid cgi or suexec/userdir. Neither is entirely satisfactory: setuid is easy to get wrong, but I like Dreamhost’s management of my configuration.[hr]
By the way, the biggest downside of sharing a single unique IP/SSL cert as I describe is that (1) Dreamhost’s easy one click installs are given their own subdomains, so can’t use it, while (2) Dreamhost’s advanced one-click installs can use this - but will all live in same user ID.

I would prefer that this not be so, but might live with it, because

(1) sending passwords, e.g. for wiki, without SSL, is bad.

(2) the standard Dreamhost packages are probably fairly secure

I most especially want maximum isolation for the CGI scripts i am writing, which I can get.


I am finally getting around to working on a “proper” security setup - I have been making do with mediawiki and known security flaws for the past few years.

Q: has dreamhost done anything to suidperl (sperl) since I last asked about this, in 2010? I’m getting a new error message. I am wondering if Dreamhost may have disabled suidperl because of the several known security issues; I am wondering if those issues were patched.


I believe that suidperl isn’t installed by default, as it isn’t required by any scripts that we use. If you’re on a VPS, you can install it with “apt-get install perl-suid”.

To the best of my knowledge, the version available there through Debian is free of any known security issues, beyond those risks inherent to any setuid script.


Thanks. It’s hard to track the “Here’s a bug, now it’s patched, here’s another bug…” history of suid. I was wondering if you knew something I did not.

I’ll have to do a bit of research, to decide between sperl (suidperl) and rolling it myself.