Bug#579746: linux-image-2.6.32-3-686-bigmem: Permission denials in devtmpfs handlers DO break the rest of the kernel.
Package: linux-image-2.6.32-3-686-bigmem
Severity: normal
Hello.
To reproduce the bug you will need some means for denying root access to
(possibly unmounted) devtmpfs filesystem.
This is easily achievable with SELinux, for example.
Required: kernel_t should be denied access to the devtmpfs fs_con type.
Debian's selinux-policy-default as of 2:0.2.20091117-2 version
provides default context for devtmpfs filesystem as system_u:object_r:tmpfs_t:s0
and contains no access rules for kernel_t to create special device nodes and
directories there, also kernel_t is not a permissive domain.
linux-image-2.6.32-3-686-bigmem as of 2.6.32-9 have devtmpfs enabled, but
userspace does not use it, so it does not get mounted and correctly labelled.
That would not be a problem if devtmpfs code would be bug-free, but it seems
that it is not prepared to see ENOPERM from vfs helpers, so that all manifests
as inability to boot with SELinux enabled and in enforced mode.
On first access to (unused and unbound) virtual console audit this (in
permissive mode):
type=AVC msg=audit(1272355156.238:105): avc: denied { search } for
pid=1686 comm=getty name=/ dev=devtmpfs ino=4
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { write } for pid=1686
comm=getty name=/ dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { add_name } for
pid=1686 comm=getty name=vcs4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { create } for
pid=1686 comm=getty name=vcs4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
or when booted into single user mode without getty and with sulogin on
/dev/console (in permissive mode)
# echo /dev/tty2
type=AVC msg=audit(1272355319.117:102): avc: denied { search } for
pid=1668 comm=getty name=/ dev=devtmpfs ino=4
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { write } for pid=1668
comm=getty name=/ dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { add_name } for
pid=1668 comm=getty name=vcs2 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { create } for
pid=1668 comm=getty name=vcs2 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
If booted in enforced mode, or just switched to enforced, any command, that
access unused (unbound) VTs
hangs the console totally. No VT switching or scrolling is possible,
ctrl-alt-del is not received,
however Sysrq-b reboots machine after a pause.
I believe, that nevertheless this denials may be fixed by writing an
appropriate SELinux module,
by allowing the kernel_t access to invisible devtmpfs floating somewhere, still
that is not
a SELinux policy bug.
Googling the discussion of kernel maintainers with devtmpfs authors made me
believe, that authors
intended devtmpfs for reduced userspace (embedded?) systems with no complex
interoperability
issues in mind.
Please do not turn CONFIG_DEVTMPFS=y in default debian kernels, that code is
not appropriately
designed and tested for everyone's use, moreover it is not required for debian
environment
to boot properly, debian have initramfs and udev.
At least until it is fixed to work in real world.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686-bigmem (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530519: [Pkg-openldap-devel] Bug#530519: /usr/bin/ldapsearch: ldap-utils: ldapsearch always cut output into 76-character length lines
On Mon, May 25, 2009 at 01:14:29PM -0700, Russ Allbery wrote: spg bugrepor...@udmvt.ru writes: This does not depend on tty width. Also no piece of code checks to see if output is a tty. Output example: mail: file:///tmp/ldapsearch-mail-gA0v8v msExchHomeServerName: file:///tmp/ldapsearch-msExchHomeServerName-y5RfdB msExchMailboxSecurityDescriptor: file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-y7G0hG msExchUserAccountControl: file:///tmp/ldapsearch-msExchUserAccountControl-K9 yMmL msExchMailboxGuid: file:///tmp/ldapsearch-msExchMailboxGuid-eHEzrQ End of example. I think it's fairly unlikely that upstream is going to change this, and I don't think this is a place where Debian should diverge from upstream. You could try to talk upstream into it, but I suspect that always folding at a safe column width is intentional. It does make it less likely that LDIF will be mangled when cut and paste or sent via e-mail. Yes, I understand that reasoning, that feature is sometimes really very useful. But there are another feature - impossibility to turn the first feature off. How about that? Anyway there is no real usefulness in sending an email with LDIF, that was generated with -tt switch, unless it is modified to have urls that refer to email attachments, and there is an mime-entry for LDIF in MUA's database to parse and display LDIF with correct program. I haven't found such program in Debian. :( But of course I still can underestimate that use case. That happens even if output is a pipe to a script and that results in mentioned files being not found by that script. I can predict what upstream's response would be to this: LDIF may be folded; that's part of the specification of LDIF. Anything that consumes LDIF has to deal with folded lines. I just asked about non-LDIF output. Just for scripts. How about -ttt switch? -ttt is like -tt, but not affected by arbitrary line length limits and outputs lines with urls as is without wrapping/folding them. Cool? I'm sympathetic to not wanting scripts to have to deal with full LDIF, but I suspect you'll find it easiest to just write a simple unfolding script and through that in the pipeline after ldapsearch. By the way, ldapsearch does not know anything about locale. That is not so bad, since there is no re(en)coding errors introduced into the data flow. But it tries to guess whether a string is printable or not using single-byte functions against UTF8-encoded multibyte data, it randomly decides about incoming strings and binary fields whether to include them into the output verbatim, or to stuff them into base64. That is another incredibly stupid feature, and it forced me to always use -tt switch to turn that feature off and always stuff everything into files and pipe the output through a really simple script. Now another feature made that simple script less readable and not simple anymore. I guess, someday the script will grow larger than ldapsearch itself and eventually augment it's functionality. :) Sad, but that makes it impossible to use ldapsearch in shell scripts AsIs, since there is really no reason for that. There is no practical reason to require extra programming to access LDAP from shell given the existence of ldapsearch, isn't it? Or should we instead include in Debian package some useful program, that will parse LDIF and will help others to use ldapsearch from shell? What do you think? By the way, perhaps there are other tools for that? I have tried all other Debian-provided packages that can run from shell, make ldap queries and write them to the stdout. I have found, that there is two alternatives: using this ldapsearch and writing my own ldapsearch. Perhaps I have overlooked something? I feel like I'm doing the common things in an incorrect way. NB: I use xterm and my terminal have a line width of 125 Yeah, one can tell from your e-mail. :) The manpage says -L Search results are display in LDAP Data Interchange Format detailed in ldif(5). That makes the reader think, that LDIF output is switched by -L switch. It would be better to explicitly express, that output is ALWAYS in LDIF format and that fact is not related to -L option, since only the version and other details of LDIF is affected by -L. The output without -L isn't actually in LDIF, just in something that looks very similar to LDIF (which the man page calls extended LDIF). Here's the full paragraph from the current man page: -L Search results are display in LDAP Data Interchange Format detailed in ldif(5). A single -L restricts the output to LDIFv1. A second -L disables comments. A third -L disables printing of the LDIF version. The default is to use an extended version of LDIF. Note the last sentence. I'm not insisting on that. That's it, I just suggested moving that sentence to the beginning
Bug#530519: /usr/bin/ldapsearch: ldap-utils: ldapsearch always cut output into 76-character length lines
Package: ldap-utils Version: 2.4.15-1.1 Severity: minor File: /usr/bin/ldapsearch This does not depend on tty width. Also no piece of code checks to see if output is a tty. Output example: mail: file:///tmp/ldapsearch-mail-gA0v8v msExchHomeServerName: file:///tmp/ldapsearch-msExchHomeServerName-y5RfdB msExchMailboxSecurityDescriptor: file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-y7G0hG msExchUserAccountControl: file:///tmp/ldapsearch-msExchUserAccountControl-K9 yMmL msExchMailboxGuid: file:///tmp/ldapsearch-msExchMailboxGuid-eHEzrQ End of example. That happens even if output is a pipe to a script and that results in mentioned files being not found by that script. Fixing the script to overcome that feature complicated the script without any need. ldapsearch would be more useful if it have a switch to turn off any formatting or to forbid formatting of urls, since that is incredibly stupid feature, since continued lines are padded by space, resulting in space being inserted into url body. By the way, almost every output device is capable of wrapping of lines by itself, there are also utilities that do output formatting. And finally, does anyone ever need that arbitrary line width limit??? I don't know whether that length is mandated by any standart, but sometimes standarts suck. NB: I use xterm and my terminal have a line width of 125 Also: The manpage says -L Search results are display in LDAP Data Interchange Format detailed in ldif(5). That makes the reader think, that LDIF output is switched by -L switch. It would be better to explicitly express, that output is ALWAYS in LDIF format and that fact is not related to -L option, since only the version and other details of LDIF is affected by -L. Thanks. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-spg (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages ldap-utils depends on: ii libc6 2.9-12 GNU C Library: Shared libraries ii libgnutls26 2.6.6-1the GNU TLS library - runtime libr ii libldap-2.4-2 2.4.15-1.1 OpenLDAP libraries ii libsasl2-22.1.22.dfsg1-23+b1 Cyrus SASL - authentication abstra Versions of packages ldap-utils recommends: ii libsasl2-modules 2.1.22.dfsg1-23+b1 Cyrus SASL - pluggable authenticat ldap-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#247985: wget: OMG! It doesn't download custom error pages.
Package: wget Version: 1.11.4-2 Followup-For: Bug #247985 Wget should have an option to actually save the message it receives after any non-200 HTTP result code. Sometimes there are really useful information in that pages. As an example for a use-case: wget is used to monitor a site periodically and that site reports some details in 404 page, that are used for diagnostics. It is not possible to record that information with wget. Why? -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-spg (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages wget depends on: ii libc6 2.9-4 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-15 SSL shared libraries wget recommends no packages. wget suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513907: libgpgme11: posix-io.c only handles filedescriptors below arbitrary (and really low) limit of 255
Package: libgpgme11
Version: 1.1.8-2
Severity: important
Tags: patch
This is really incorrect, since it makes gpgme work for years for most of it's
users, but not for all.
Look at posix-io.c, there is array notify_table.
Just can you explain, why it have 256 elements, but not, say 257 or 258? :)
Maybe there should be something like FD_SETSIZE and a sound error message if
a filedescriptor does not fit into notify_table? (Yes, FD_SETSIZE is larger
than 256 on my system, and perhaps on your system too.)
That will be OK, since filedescriptors are later used in select() and
every fd FD_SETSIZE makes no sense for us.
Why this bug is so bad? Because it will be hard to reproduce it in
laboratory environment with everything except gpgme itself cut off,
gpgme creates very little number of fds by itself.
So it silently emerges only when used inside very busy application with more
than 256 files open simultaneously.
With patch applied it will SILENTLY fail only when there are more than
FD_SETSIZE file open. It is not-OKAY-but-works-for-me patch :(
Yet there should be some error notification instead of GPG_ERR_GENERAL.
Thanks.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-spg (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgpgme11 depends on:
ii gnupg 1.4.9-3GNU privacy guard - a free PGP rep
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgpg-error0 1.4-2 library for common error values an
ii libpth20 2.0.7-12 The GNU Portable Threads
libgpgme11 recommends no packages.
Versions of packages libgpgme11 suggests:
ii gpgsm 2.0.9-3.1 GNU privacy guard - S/MIME version
-- no debconf information
--- src/posix-io.c~ 2008-12-23 21:24:42.0 +0400
+++ src/posix-io.c 2009-02-02 14:16:50.0 +0400
@@ -77,7 +77,7 @@
{
_gpgme_close_notify_handler_t handler;
void *value;
-} notify_table[256];
+} notify_table[FD_SETSIZE];
int
Bug#509583: stumpwm does not tolerate non-ascii characters on input
Package: stumpwm Version: 1:20080721-2 Severity: important Tags: l10n It is not possible to input cyrillic characters into stumpwm prompts, so it is not possible to exec programs with cyrillic arguments. While other X-applications does correctly receive cyrillic symbols from X, stumpwm does magically receive ASCII symbols as if group was not switched by xkb. That is, I receive 'f' instead of 'cyrillic-a', 'n' instead of 'cyrillic-t', etc. (Latin-f and cyrillic-a placed on the same button on keyboard - for those, who do not use cyrillic keyboards.) Also, every time group-switch or group-toggle buttons are pressed when stumpwm prompt window have focus, one unprintable character appears. (I personally use Menu and Logo buttons for that) Group toggle also happens, but that is reflected only on other applications, stumpwm does receive cyrillic as ascii symbols. I cannot remember any other X application, that demonstrate similar behavior. It seems like stumpwm use it's own keybinding and ignores xkb keymap totally. Is it a feature? Next. When i put this: (set-font -xos4-terminus-bold-r-normal--14-140-72-72-c-80-iso10646-1) into ~/.stumpwmrc, I get error: ;; Loading file /var/cache/common-lisp-controller/1000/clisp/stumpwm/version.fas ... ;; Loaded file /var/cache/common-lisp-controller/1000/clisp/stumpwm/version.fas 0 errors, 0 warnings NIL ;; Loading file /home/user/.stumpwmrc ... ;; Loaded file /home/user/.stumpwmrc *** - unknown character set ISO-10646-1 Bye. stumpwm dies then. Is it really unknown? When 'iso10646-1' is changed to 'koi8-r' in font name, stumpwm loads itself OK. More to say, 'isoblablabla-bla' also makes no load error, but there is no such font, of course. I swear, font name '-xos4-terminus-bold-r-normal--14-140-72-72-c-80-iso10646-1' is copied verbatim from xlsfonts. Next. Stumpwm crashes at the moment some window is opened or closed. This cannot be reproduced regularly. Last crash happened when oowriter window opened, previous - when oowriter window closed. Right now I cannot trigger that again, sorry for silly report. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-spg (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages stumpwm depends on: ii cl-ppcre1.3.2-2 Portable Regular Express Library f ii clisp 1:2.44.1-4.1 GNU CLISP, a Common Lisp implement ii common-lisp-controller 6.17 Common Lisp source and compiler ma stumpwm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483695: nagiosgrapher: setgid() in daemon does not work (and return code not checked)
Package: nagiosgrapher Version: 1.6.1rc5-5 Severity: normal 1. When initially run as root (as is default in Debian for now), nagiosgrapher daemon changes uid and gid to the values, specified in configuration. The bug is that it does so in the exactly specified order: first it change it's uid (from 0) then it change it's gid which is obviously incorrect and cannot happen succesfully. As a consequence all files gets created with root group. (Is this a security bug?) Suggest invoking setuid() after setgid() - it works then. I also would like to see a warning message of complain if any of setuid() or setgid() fail. Now there are no checks on what did they return. 2. create_pipe() function creates pipe with too permissive modes - 0666, suggest 0660 (after fixing first bug it will become practical) Anyway, this is really a security-related bug. Bye. And Big Thanks to Debian people. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-spg (SMP w/2 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453310: locale horrors
OMG...
The source of described behavior is in utf8.c:joe_locale()
It directly manipulates LC_ environment variables, instead of leaving
that to setlocale or other method.
First it does
utf8.c:joe_locale(void):347
s=(unsigned char *)getenv(LC_ALL);
if (!s) {
s=(unsigned char *)getenv(LC_CTYPE);
if (!s) {
s=(unsigned char *)getenv(LANG);
}
}
... then
utf8.c:joe_locale(void):365
locale_lang = s;
... and at the end
utf8.c:joe_locale(void):422
init_gettext(locale_lang);
So it sets the gettext language to the contents of the LC_ALL or else LC_CTYPE
or else LANG environment variables. And that do not depends on whether or
not setlocale available on the system!!!
1. The gettext language should be initialized from LC_MESSAGES, not from
LC_CTYPE
2. This should be only done when setlocale is unavailable.
3. This is the error when setlocale is available!
4. gettext language should be initialized from setlocale (LC_MESSAGES, NULL)
when setlocale is available.
Trying to provide quick patch fixing that bug, I have found, that
presence of HAVE_SETLOCALE depends on presence CODESET macro.
CODESET defined in langinfo.h
langinfo.h included only when HAVE_SETLOCALE defined.
HAVE_SETLOCALE undefined earlier if CODESET is not defined...
utf8.c:22
/* If it looks old, forget it */
#ifndef CODESET
#undef HAVE_SETLOCALE
#endif
#if defined(HAVE_LOCALE_H) defined(HAVE_SETLOCALE)
# include locale.h
# include langinfo.h
#endif
end of utf8.c fragment
It seems, that joe always uses its own locale functions [I have no knowledge
of...]
If that is a compatibility feature, I will not provide any patches fixing that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453310: joe: misuses value of LC_CTYPE as value of LC_MESSAGES when displaying messages
Package: joe Version: 3.5-1.1 Severity: normal Tags: l10n When I set the LC_MESSAGES=C, joe continues to use messages from russian translation. (/etc/joe/lang/ru.po) My `locale` is as follows: LANG= LC_CTYPE=ru_RU.KOI8-R LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=C LC_IDENTIFICATION=C LC_ALL= Note the empty LANG and LC_ALL, all the variables were set explicitly. The reason I set the LC_MESSAGES to C while LC_CTYPE to ru_RU.KOI8-R is that I often edit files in russian KOI8-R encoding, but still prefer to see the original software author's messages and not the translated ones. I natively speak and read Russian, but I hate stupid translations (though I do not insist on stupidity of current joe translation!). Just like to see what did exactly author mean, and not worrying about the possibility, that unknown translator misunderstood something somehow. According to locale(1) LC_CTYPE is for Character classification and case conversion., while LC_MESSAGES is for Formats of informative and diagnostic messages and interactive responses. So the bug appears when you set LC_CTYPE=ru_RU.KOI8-R willing to edit the russian koi8-r text, and in addition to that text you see translated prompts, messages and ever DEADJOE contains comments from joe in russian. When unsetting LC_CTYPE, joe becomes Engish-speaking but looses the ability to pass 8-bit KOI8-R chars to the terminal. PS: writing this report with joe :) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash Versions of packages joe depends on: ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libncurses5 5.6+20071013-1 Shared libraries for terminal hand joe recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
