Bug#344313: cryptsetup: unable to create map with libdevmapper1.02
Package: cryptsetup
Version: 20050111-4+b1
Severity: grave
Justification: renders package unusable
After last nights upgrade to cryptsetup 20050111-4+b1, I'm unable to map new or
existing devices. Only by relinking to libdevmapper1.01 does it work.
gozer:/tmp# dd if=/dev/zero of=test bs=1M count=4
4+0 records in
4+0 records out
4194304 bytes (4.2 MB) copied, 0.047132 seconds, 89.0 MB/s
gozer:/tmp# losetup /dev/loop0 test
gozer:/tmp# cryptsetup create test /dev/loop0
Command failed: Invalid argument
gozer:/tmp# ./cryptsetup-1.01 create test /dev/loop0
Enter passphrase:
A strace between the two look similar, but when cryptsetup should open the
device and prompt for the passphrase, it errors out.
# 1.02
8658 open(/proc/misc, O_RDONLY|O_LARGEFILE) = 3
8658 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
8658 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
8658 read(3, 63 device-mapper\n 1 psaux\n175 ..., 1024) = 48
8658 close(3) = 0
8658 munmap(0x40017000, 4096) = 0
8658 stat64(/dev/mapper/control, {st_mode=S_IFCHR|0600, st_rdev=makedev(10,
63), ...}) = 0
8658 open(/dev/mapper/control, O_RDWR|O_LARGEFILE) = 3
8658 open(/proc/devices, O_RDONLY|O_LARGEFILE) = 4
8658 fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
8658 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
8658 read(4, Character devices:\n 1 mem\n 2 p..., 1024) = 424
8658 read(4, , 1024) = 0
8658 close(4) = 0
8658 munmap(0x40017000, 4096) = 0
8658 ioctl(3, DM_VERSION, 0x8096548) = 0
8658 ioctl(3, DM_TABLE_STATUS, 0x8096548) = -1 ENXIO (No such device or
address)
8658 close(3) = 0
8658 write(2, Command failed, 14)= 14
8658 write(2, : Invalid argument\n, 19) = 19
8658 exit_group(1) = ?
# 1.01
8870 stat64(/dev/mapper/control, {st_mode=S_IFCHR|0600, st_rdev=makedev(10,
63), ...}) = 0
8870 open(/dev/mapper/control, O_RDWR|O_LARGEFILE) = 3
8870 ioctl(3, DM_VERSION, 0x804e328) = 0
8870 ioctl(3, DM_TABLE_STATUS, 0x804e2e8) = -1 ENXIO (No such device or
address)
8870 open(/dev/loop0, O_RDONLY|O_LARGEFILE) = 4
8870 ioctl(4, BLKGETSIZE64, 0xbfa35f10) = 0
8870 close(4) = 0
8870 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
8870 open(/dev/tty, O_RDWR|O_CREAT|O_TRUNC, 0666) = 4
I found a similar report
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/1312 on
the dm-crypt mailing list, but noone responded and he said crtypsetup
mysteriously started working at a later date.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages cryptsetup depends on:
ii dmsetup 2:1.02.02-1 The Linux Kernel Device Mapper use
ii libc62.3.5-9 GNU C Library: Shared libraries an
ii libdevmapper1.02 2:1.02.02-1 The Linux Kernel Device Mapper use
ii libgcrypt11 1.2.2-1 LGPL Crypto library - runtime libr
ii libgpg-error01.1-4 library for common error values an
ii libpopt0 1.7-5 lib for parsing cmdline parameters
cryptsetup recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324017: Cron daemon dies when a cronjob is about to start
On Sunday, August 21, 2005 at 12:15AM, Javier Fern?ndez-Sanguino Pe?a wrote:
I'm sorry but I can't reproduce this and you're the only one seeing this.
I'm pretty sure that if 3.0pl1-88 introduce a bug of this kind I would
be flooded with similar bug reports already since it is a base package.
Could you please send a trace of the cron daemon _before_ a cronjob
starts so we can actually determine why it's dying? You can do this
with 'strace' (use the -p option to tell it which pid to trace and the -f
option to follow forks)
I'm having this problem also, but haven't tried 3.0pl1-87. I'm also having
problems with my clock running too fast, so I'm frequently running ntpdate
until I can figure out what's going on when I get back to work on Monday. Not
sure if that would have anything to do with it...
I've rebuilt the cron daemon with -g to try and get something good out of the
core, but now it's not crashing. :/
A strace I captured earlier looks like this:
[snip]
1523 open(/etc/cron.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
1523 fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
1523 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
1523 getdents64(4, /* 5 entries */, 4096) = 136
1523 lstat64(/etc/cron.d/sendmail, {st_mode=S_IFREG|0644, st_size=7, ...}) = 0
1523 open(/etc/cron.d/sendmail, O_RDONLY) = 5
1523 fstat64(5, {st_mode=S_IFREG|0644, st_size=7, ...}) = 0
1523 close(5) = 0
1523 lstat64(/etc/cron.d/php4, {st_mode=S_IFREG|0644, st_size=456, ...}) = 0
1523 open(/etc/cron.d/php4, O_RDONLY) = 5
1523 fstat64(5, {st_mode=S_IFREG|0644, st_size=456, ...}) = 0
1523 close(5) = 0
1523 getdents64(4, /* 0 entries */, 4096) = 0
1523 close(4) = 0
1523 open(crontabs, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
1523 fstat64(4, {st_mode=S_IFDIR|S_ISVTX|0730, st_size=4096, ...}) = 0
1523 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
1523 getdents64(4, /* 4 entries */, 4096) = 104
1523 open(crontabs/root, O_RDONLY|O_NOFOLLOW) = 5
1523 fstat64(5, {st_mode=S_IFREG|0600, st_size=1011, ...}) = 0
1523 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
It seemed stable when I commented everyone's crontabs.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324017: Cron daemon dies when a cronjob is about to start
On Sunday, August 21, 2005 at 01:57AM, Javier Fern?ndez-Sanguino Pe?a wrote: On Sat, Aug 20, 2005 at 07:28:25PM -0400, Rick Friedman wrote: Oh, and BTW, the only change in -88 that might affect cron's behaviour is either SElinux support or the enabling of pam_limits.so. You might want to review /etc/security/limits.conf and see that it has sane values there just in case. I don't have SElinux enabled and there's only comments in that file. I know this may not help much, but here's some bits from the core of the stripped binary. Loaded symbols for /lib/ld-linux.so.2 #0 0x400a4e69 in free () from /lib/tls/libc.so.6 (gdb) bt #0 0x400a4e69 in free () from /lib/tls/libc.so.6 #1 0x40033e6c in freecon () from /lib/libselinux.so.1 #2 0x0804af20 in ?? () #3 0x000a6575 in ?? () #4 0xbfefad18 in ?? () [ on and on ] #21 0x401739d4 in daylight () from /lib/tls/libc.so.6 [ and on some more ] In -88, u-scontext is set to NULL if get_security_context() fails (i think) and in free_user() there's a freecon() call on u-scontext but no NULL check. Maybe that's where the problem is? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324017: Cron daemon dies when a cronjob is about to start
On Sunday, August 21, 2005 at 03:20AM, Javier Fern?ndez-Sanguino Pe?a wrote:
On Sat, Aug 20, 2005 at 07:51:17PM -0500, Mike Hokenson wrote:
I'm not sure what your patch looks like, but just testing for a NULL
u-scontext didn't work, I had to do this:
Aggg.. you are right, I don't think clearly this late, the problem is that
u-scontext is undefined, that's why free() segfaults.
How about this patch? It should also fix other segfaults which were fixed
on a Fedora patch.
Javier
diff -Nru cron-3.0pl1-88/do_command.c cron-3.0pl1-91/do_command.c
--- cron-3.0pl1-88/do_command.c 2005-08-21 03:17:04.0 +0200
+++ cron-3.0pl1-91/do_command.c 2005-08-21 03:13:58.0 +0200
@@ -331,7 +331,7 @@
fprintf(stdout,error);
#endif
#ifdef WITH_SELINUX
- if (is_selinux_enabled() 0) {
+ if ((is_selinux_enabled() 0) (u-scontext != 0L)) {
security_context_t scontext;
if (setexeccon(u-scontext) 0) {
if (security_getenforce() 0) {
diff -Nru cron-3.0pl1-88/user.c cron-3.0pl1-91/user.c
--- cron-3.0pl1-88/user.c 2005-08-21 03:17:04.0 +0200
+++ cron-3.0pl1-91/user.c 2005-08-21 03:15:37.0 +0200
@@ -36,7 +36,7 @@
static int get_security_context(char *name, int crontab_fd, security_context_t
*rcontext, char *tabname) {
-security_context_t scontext;
+security_context_t scontext=NULL;
security_context_t file_context=NULL;
struct av_decision avd;
int retval=0;
@@ -50,6 +50,7 @@
log_it(name, getpid(),
No security context but SELinux in permissive mode,
continuing, tabname);
+ return 0;
}
}
@@ -133,7 +134,8 @@
free_entry(e);
}
#ifdef WITH_SELINUX
-freecon(u-scontext);
+ if (u-scontext)
+ freecon(u-scontext);
#endif
free(u);
}
@@ -175,6 +177,7 @@
u-crontab = NULL;
#ifdef WITH_SELINUX
+ u-scontext = NULL;
if (is_selinux_enabled() 0) {
char *sname=uname;
if (pw==NULL) {
Yep, works good.
(sorry, forgot to cc everyone on the reply to your other message heh).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
