(Sorry to revisit such an old bug, but we keep running into it now and
then...)
If this is deemed to be a PAM bug, can this bug report just be re-tagged
as a PAM bug and reassigned to the appropriate party?
The high-level problem -- cron doesn't work for Kerberos/Hesiod users
unless you manually
Package: linux-image-3.9-0.bpo.1-amd64
Version: 3.9.6-1~bpo70+1
Other possibly relevant packages: Xen, lvm (2.02.95-7), fio (2.0.8-2),
libaio1:amd64 (0.3.109-3).
I've been seeing "fio" (flexible I/O tester) fail to read back the
expected data from a storage device when using 512B blocks under a
Bob Proulx wrote:
The version in Squeeze does not suffer from
this problem. As Tony noted it has already been fixed upstream. It
has already propagated into Debian Unstable Sid and is only waiting
for the release of Squeeze as Stable.
That's good to know; thank you. I'll pass that on t
Package: unifdef
Version: 1.0+20030701-1
Severity: important
Running "unifdef -UBARF" over the file:
char foo[] = "rm -rf /*";
causes a warning that the file ends within a comment. That's not so
bad. However, since the text following up to the next "*/" will be
considered to be in a comme
Package: libcrypto++8
Version: 5.6.0-2
Severity: important
The version of libcrypto++ 5.6.0 shipped by Debian includes a bug in
the 32-bit x86 assembly code for sha256. Address checks (current
pointer vs end-of-message pointer as we process the input block by
block) are done with signed-arithmet
Package: pidgin
Version: 2.4.3-4lenny5
Severity: normal
I recently started trying to use pidgin in a new environment, using
one Jabber account with password authentication. However, it seems to
crash on me almost daily, and usually while I've got the window
iconified or buried, or I've wandered
Package: sudo
Version: 1.6.9p17-2
Severity: grave
Tags: security patch
Justification: user security hole
I'm investigating #556562 (wildcard "*" sudoers rules are broken),
filed by a co-worker. I discovered it's your basic use-after free
problem, fixed by the following patch:
--- parse.c 20
Aurelien Jarno wrote:
Wouldn't it be possible to also use Kerberos for shadow information, as
it is actually where the encrypted passwords are stored?
Kerberos doesn't necessarily have the information in its database, and
the protocol provides no way to pass the information around.
Other
Aurelien Jarno wrote:
hesiod is not supposed to be used to provide password. Even if used that
way, I don't really see the point of providing a shadow database though
hesiod, as the data will anyway be public, as published in the DNS.
Certainly not password authentication data, but it can be
Package: libc6
Version: 2.7-18
Severity: normal
File: /lib/libnss_hesiod.so.2
We've found that since updating to lenny, cron jobs for normal,
non-local users (who are listed in hesiod) aren't being run. Adding
entries to /etc/shadow works around it. The following message gets
logged, and the cr
hosen port.
(And yes, I agree with Russ's assessment in his message in the Debian
tracking system, that it's probably going to be low-priority for us,
but a good patch would be welcome.)
--
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium
--
To UNSUBSCRIBE, email to
On Jul 9, 2007, at 12:01, Russ Allbery wrote:
Ken, I assume from the previous bug discussion that this was
already fixed
in 1.6? It looks like that file now includes k5-int.h and k5-int.h
now
includes time.h.
Yes, that's correct, this shouldn't be a problem in the 1.6 branch.
Ken
--
To
I just tried on our x86_64 etch system (1.4.4-7etch1 kadmind
installed), and with a few simple tests, couldn't reproduce the
problem. I set up a realm FOOBAR.X with a user principal ken with
admin privileges, ran "kadmin -p ken -q 'cpw ken'" and then "kpasswd"
a few times, sometimes re-usi
13 matches
Mail list logo
