Your message dated Thu, 8 Aug 2013 22:30:34 +0200
with message-id <[email protected]>
and subject line Works with recent versions of policy
has caused the Debian Bug report #595576,
regarding selinux-policy-default: Quietly prevents mdadm from writing to
unconfined terminals
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
595576: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595576
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: selinux-policy-default
Version: 2:0.0.20080702-6
Severity: normal
Lenny's refpolicy seems to prevent mdadm from writing to an interactive
(unconfined) tty, although I'm somewhat mystified as to the specific cause.
mdadm has its own domain, defined by the raid refpolicy module; run as a
monitoring daemon, as it often is, it lives in mdadm_t.
Run from an unconfined_t shell, though, it's unable to write to stdout or
stderr, despite that it does seem able to read the block devices and do its
other work. Disabling enforcing mode restores its ability to write to the
tty, as does piping stdout & stderr through cat. Running mdadm under strace
shows no -EPERM errors on the writes to fds 1 and 2 (and there are no kernel
audit errors logged), although the output never reaches the terminal.
Some sample output (or lack thereof):
root@atlantic:/# mdadm
root@atlantic:/# mdadm 2>&1 | cat
Usage: mdadm --help
for help
root@atlantic:/# strace -f mdadm
execve("/sbin/mdadm", ["mdadm"], [/* 18 vars */]) = 0
brk(0) = 0x69a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc73bdba000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc73bdb8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=38835, ...}) = 0
mmap(NULL, 38835, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc73bdae000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\342\1\0\0\0\0\0@"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0
mmap(NULL, 3482232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fc73b84d000
mprotect(0x7fc73b997000, 2093056, PROT_NONE) = 0
mmap(0x7fc73bb96000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0x7fc73bb96000
mmap(0x7fc73bb9b000, 17016, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc73bb9b000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc73bdad000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc73bdac000
arch_prctl(ARCH_SET_FS, 0x7fc73bdac6e0) = 0
mprotect(0x7fc73bb96000, 12288, PROT_READ) = 0
munmap(0x7fc73bdae000, 38835) = 0
gettimeofday({1283677360, 117108}, NULL) = 0
getpid() = 12136
write(2, "Usage: mdadm --help\n for help\n"..., 31) = 31
exit_group(2) = ?
root@atlantic:/# mdadm --examine --scan
root@atlantic:/# mdadm --examine --scan | cat
ARRAY /dev/md10 level=raid1 num-devices=3
UUID=da807026:5ef36d4f:595723e4:2ede6c7b
ARRAY /dev/md3 level=raid1 num-devices=3
UUID=821dfec2:8f8b8b88:cffd4f39:f63eeeef
spares=1
ARRAY /dev/md2 level=raid1 num-devices=3
UUID=8b467d04:247f01dc:6e891da9:5432580b
spares=1
ARRAY /dev/md4 level=raid1 num-devices=3
UUID=65185cc9:469ef038:f4508a8a:227677f3
During that first 'mdadm --examine --scan', which takes long enough to run that
I could catch it with a ps Z, it's in the expected domain (as is the
monitoring daemon):
root@atlantic:/# ps axZ|grep mdadm | grep -v grep
system_u:system_r:mdadm_t:s0 3987 ? Ss 0:04 /sbin/mdadm
--monitor --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog
unconfined_u:system_r:mdadm_t:s0-s0:c0.c1023 10913 ? D 0:00 mdadm --examine
--scan
-- System Information:
Debian Release: 5.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages selinux-policy-default depends on:
ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f
ii libselinux1 2.0.65-5 SELinux shared libraries
ii libsepol1 2.0.30-2 Security Enhanced Linux policy lib
ii policycoreutils 2.0.49-8 SELinux core policy utilities
ii python 2.5.2-3 An interactive high-level object-o
Versions of packages selinux-policy-default recommends:
ii checkpolicy 2.0.16-1 SELinux policy compiler
ii setools 3.3.5.ds-5 tools for Security Enhanced Linux
Versions of packages selinux-policy-default suggests:
pn logcheck <none> (no description available)
pn syslog-summary <none> (no description available)
-- debconf-show failed
--- End Message ---
--- Begin Message ---
Hi,
I tried today in a freshly installed wheezy with selinux enabled and
mdadm had no problems writing to the tty, with and without raid.pp
loaded and using unconfined_u root as well as user_u user. As the bug
is also very old and hasn't received new info in two and a half years,
I am closing this bug.
Cheers,
Mika
--
signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________
SELinux-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel
