Summary: | app-admin/webapp-config-1.50-r3 blocks access to keyboard | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hugo Mildenberger <Hugo.Mildenberger> |
Component: | Hardened | Assignee: | Gentoo Web Application Packages Maintainers <web-apps> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | web-apps |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info =app-admin/webapp-config-1.50.16-r3 |
Description
Hugo Mildenberger
2009-11-13 14:47:30 UTC
Created attachment 210131 [details]
emerge --info =app-admin/webapp-config-1.50.16-r3
When looking at the strace output, read(0,..) simply returns 0, no error. Using the following test program instead of builtin function read() ... #include <stdio.h> #include <errno.h> #include <string.h> int main(int argc, const char **argv) { const char *prompt = argc >1 ? argv[1] : ""; const char *dev="/dev/stdin"; FILE *fp=fopen(dev,"r"); if ( fp == NULL) { fprintf(stderr,"error opening '%s': %m\n",dev); return -errno; } fprintf(stderr,"%s",prompt); char buffer[80]; memset(buffer,0,sizeof(buffer)); if ( fscanf(fp,"%s",buffer) != EOF ) { fprintf(stdout,"%s",buffer); return 0; } fprintf(stderr,"\nerror reading '%s': %m\n",dev); return -errno; } ... leads to a similar behaviour; except that this time read(3, ...) returns 0. These lines from strace output may give an hint ... [pid 26436 is the program listed above] lstat64("/proc/26436/fd/0", {st_mode=S_IFLNK|0500, st_size=64, ...}) = 0 readlink("/proc/26436/fd/0", "pipe:[107564]"..., 4095) = 13 lstat64("/proc/26436/fd/pipe:[107564]", 0x5a471c7c) = -1 ENOENT ... to a Gentoo bug (possibly fixed with sandbox-2.2) describing a related problem: http://bugs.gentoo.org/show_bug.cgi?id=288863. However, my problem isn't at all solved by installing sandbox-2.2, even though sandbox 'echo | touch /dev/stdin' runs smoothly with the new version. Yet I now found a fully functional workaround. "read() -p prompt\>" write the prompt to stderr, which is somehow redirected in webapp-configs's context, resulting in a buffered stderr output. Consequently, redirecting additionally the output of read() to /dev/tty does the trick: prompt_user() { exec 4<>/dev/tty read -u 4 -t 20 -p "hello" myvar 2>&4 \ || die "interactive read timed out after 20 seconds: $?" exec 4>&-; echo "${myvar}"; } I'm finally setting the component to "hardened", because I currently do not know if this is problem is specific for the hardened platform only. Devan, can you take a look at this and make a recommendation. |