While it's possible that it's a fluke of a package I installed or the VPS image, it appears that /usr/local and /usr/local/bin (both of which are owned by root:staff) are group-writable by default on Debian Squeeze. Is there a reason that they need to be?
Does this PHP-CGI security issue (CVE-2012-1823) affect PHP when it's running under individual regular-user accounts with mod_fcgid?
The wrapper .fcgi script I've been using is:
#!/bin/bash
PHPRC=$PWD/../etc/php5
export PHPRC
umask 022
export PHP_FCGI_CHILDREN
SCRIPT_FILENAME=$PATH_TRANSLATED
export SCRIPT_FILENAME
exec /usr/bin/php-cgi
I'm using apache2 (2.2.3) to serve a site where I'd like to have clients authenticate with certificates. Since I only need to verify that a user presenting a particular certificate is the same user who has presented that certificate in the past, the CA signing the certificate is irrelevant. It seems, though, that using SSLVerifyClient require requires SSLCACertificateFile ... (or SSLCACertificatePath ...), and then apache will only accept certificates signed by a CA in that file/path. Is there a way to get apache to accept any client certificate, regardless of the issuing/singing CA? (i.e. verify that the client has the corresponding private key to the presented public key, but not bother verifying the issuing/signing CA)
Suppose I have a site that I want users to be able to log into with client certificates. As I understand it, the client is presenting the site with the public half of a keypair and proving that they have the corresponding private half. Is that correct? If so, then isn't checking that a client is presenting a known (previously-authorized) public key sufficient to know that it's a known user, without the certificate having been signed by a trusted CA?
There are some web sites that I can only access from a limited set of machines, but I can ssh into some of these machines (only as a regular user) and use ssh -D to set up a SOCKS proxy on my local machine, through which I can access the sites.
What I'd prefer, however, is to be able to go to http://server.that.i.control/some_path/ (secured in some fashion) and have it be a reverse-proxy through ssh -D or something similar on server.that.i.control.
Is this doable, preferably with apache or lighttpd on server.that.i.control?
My understanding is that if I have the nameservers for both example1.com and example2.us set to ns1.example2.us and ns2.example2.us, looking up www.example1.com will:
If instead, we have the nameservers for both example1.com and example2.com set to ns1.example2.com and ns2.example2.com, looking up www.example1.com will:
Am I correct that in this case, there are only these two steps in the lookup? Specifically, I seem to be experiencing a volume of lookups in example2.com that suggests that lookups for example1.com are not always using the glue records, resulting in an extra step where ns1.example2.com and/or ns2.example2.com are looked up by querying ns1.example2.com and/or ns2.example2.com.
(edited to highlight my minor questions buried in the first example and to try to clarify my primary question at the end.)
Maybe some diagrams will help, since I think I'm explaining this badly. Here's my understanding of what should happen when looking up www.example.com if example.com's nameservers are ns1.host.us and ns2.host.us:
The third lookup step seems to be happening nearly universally, but doesn't entirely make sense to me. Should that third step really be there?
Here's my understanding of what should happen when looking up www.example.com if example.com's nameservers are ns1.host.com and ns2.host.com:
Is my understanding of this case correct?
Here's what I think might be happening with around 1/3 of the lookups for www.example.com with nameservers ns1.host.com and ns2.host.com (based on the number and timing of queries to the nameservers for various domains):
Is this actually possible and/or does it represent a badly-behaved client?
RFC-952 (last sentence of point 1 under Assumptions) prohibits single-character host names and I have had experiences (over 7 years ago summer of 2002) where some services would refuse to work with single-character host names (because such names were not standards-compliant), but I have seen a number of single-character host names in use in the past few years. Are single-character host names now valid? (If so, what is the proper validation reference?)
edit (to consolidate some information from the answers): various aspects of DNS seem to be defined in several RFCs, including 1035, 1123, and 2181. From RFC-2181 section 11:
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.
From RFC-1123 section 6.1.3.5:
The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets. Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names. In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].
From RFC-1123 section 2.1:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
And finally, as originally referenced, from RFC-952:
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.
It is from following this chain that I originally came to say that RFC-952 prohibits single-character host names.