|
7 | 7 | * |
8 | 8 | * |
9 | 9 | * IDENTIFICATION |
10 | | - * $PostgreSQL: pgsql/src/backend/tsearch/ts_utils.c,v 1.3 2007/08/25 00:03:59 tgl Exp $ |
| 10 | + * $PostgreSQL: pgsql/src/backend/tsearch/ts_utils.c,v 1.4 2007/09/04 02:16:56 tgl Exp $ |
11 | 11 | * |
12 | 12 | *------------------------------------------------------------------------- |
13 | 13 | */ |
@@ -38,22 +38,22 @@ get_tsearch_config_filename(const char *basename, |
38 | 38 | { |
39 | 39 | charsharepath[MAXPGPATH]; |
40 | 40 | char*result; |
41 | | -constchar*p; |
42 | 41 |
|
43 | 42 | /* |
44 | | - * Weenforce thatthe basenameis all alpha characters. This may be |
45 | | - * overly restrictive, but we don't want to allow access to anything |
| 43 | + * Welimitthe basenameto contain a-z, 0-9, and underscores. This may |
| 44 | + *beoverly restrictive, but we don't want to allow access to anything |
46 | 45 | * outside the tsearch_data directory, so for instance '/' *must* be |
47 | | - * rejected. This is the same test used for timezonesets names. |
| 46 | + * rejected, and on some platforms '\' and ':' are risky as well. |
| 47 | + * Allowing uppercase might result in incompatible behavior between |
| 48 | + * case-sensitive and case-insensitive filesystems, and non-ASCII |
| 49 | + * characters create other interesting risks, so on the whole a tight |
| 50 | + * policy seems best. |
48 | 51 | */ |
49 | | -for (p=basename;*p;p++) |
50 | | -{ |
51 | | -if (!isalpha((unsignedchar)*p)) |
52 | | -ereport(ERROR, |
53 | | -(errcode(ERRCODE_INVALID_PARAMETER_VALUE), |
54 | | -errmsg("invalid text search configuration file name \"%s\"", |
55 | | -basename))); |
56 | | -} |
| 52 | +if (strspn(basename,"abcdefghijklmnopqrstuvwxyz0123456789_")!=strlen(basename)) |
| 53 | +ereport(ERROR, |
| 54 | +(errcode(ERRCODE_INVALID_PARAMETER_VALUE), |
| 55 | +errmsg("invalid text search configuration file name \"%s\"", |
| 56 | +basename))); |
57 | 57 |
|
58 | 58 | get_share_path(my_exec_path,sharepath); |
59 | 59 | result=palloc(MAXPGPATH); |
|