Bug#1019428: Please, fix sudo to cope with libgcrypt changes
I believe this is fixed by: https://www.sudo.ws/repos/sudo/rev/ebf9a6477d5d I was able to reproduce the issue by running "make check" and checking syslog. - todd
Bug#1003304: debsigs uses a predictable /tmp directory name
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch
Dear Maintainer,
When debsigs creates its temporary directory, it just uses
"/tmp/debsigndeb.$$" where "$$" is the process ID. Using a predictable
temporary file name can be a security issue if an attacker is able to
create the path first. However, Since debsig uses a temporary directory,
not a file, only a denial of service attack is possible.
It would be safer to use the built-in mkdtemp() function when creating
the temporary directory, which creates a random name and will retry
as needed if the chose name already exists.
The attached fix is also in gitlab as:
https://gitlab.com/debsigs/debsigs/-/merge_requests/2
- todd
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debsigs depends on:
ii binutils 2.35.2-2
ii gnupg 2.2.27-2
ii perl 5.32.1-4+deb11u2
Versions of packages debsigs recommends:
ii debsig-verify 0.23+b2
debsigs suggests no packages.
-- no debconf information
commit 9cd7c457001ec6b10fc77ae370046583511c6d24
Author: Todd C. Miller
Date: Sun Sep 26 19:31:20 2021 -0600
Use mkdtemp() to create the temp dir instead of using a predictable name.
diff --git a/debsigs b/debsigs
index ee77ff8..903ee14 100644
--- a/debsigs
+++ b/debsigs
@@ -25,6 +25,7 @@ use Debian::debsigs::forktools ':all';
use Debian::debsigs::gpg;
use Getopt::Long;
use List::Util qw(first);
+use File::Temp qw(:mktemp);
use IO::File;
use POSIX ":sys_wait_h";
@@ -185,8 +186,8 @@ sub cmd_delete($) {
sub mktempdir() {
- mkdir("/tmp/debsigndeb.$$", 0700) or die "couldn't mkdir: $!";
- return "/tmp/debsigndeb.$$";
+ my $dir = mkdtemp("/tmp/debsigs.XX") or die "couldn't mkdtemp: $!";
+ return $dir;
}
sub syntax($) {
Bug#1003302: debsigs: Do not hard-code the path to gpg.
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch
Dear Maintainer,
The debsigs utility uses a mix of fully-qualified and unqualified paths
when invoking gpg. There's no need to explicitly run /usr/bin/gpg as
perl will use execvp() to invoke the command (which searches PATH).
Using the PATH to find gpg makes it easier to run debsigs on other,
non-Debian platforms.
The attached fix is also in gitlab as:
https://gitlab.com/debsigs/debsigs/-/merge_requests/3
- todd
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debsigs depends on:
ii binutils 2.35.2-2
ii gnupg 2.2.27-2
ii perl 5.32.1-4+deb11u2
Versions of packages debsigs recommends:
ii debsig-verify 0.23+b2
debsigs suggests no packages.
-- no debconf information
commit b2dbd703b1b40d6e616b2246a84ef3b53e578497
Author: Todd C. Miller
Date: Sun Sep 26 19:51:18 2021 -0600
Do not hard-code the path to gpg.
There's no need to do this as perl will use execvp() which searches PATH.
diff --git a/debsigs b/debsigs
index 25b5d44..dc12b02 100644
--- a/debsigs
+++ b/debsigs
@@ -100,7 +100,7 @@ sub cmd_sign($) {
# Why doesn't this work?
- # my $gpgout = forktools::forkboth($arfd, $sigfile, "/usr/bin/gpg",
+ # my $gpgout = forktools::forkboth($arfd, $sigfile, "gpg",
#"--detach-sign");
my @cmdline = ("gpg", "--openpgp", "--detach-sign");
diff --git a/gpg.pm b/gpg.pm
index c624b4e..d939f2c 100644
--- a/gpg.pm
+++ b/gpg.pm
@@ -28,9 +28,7 @@ our $VERSION = '1.06';
sub getkeyfromfd {
my $forkfd = shift @_;
- my ($gpgfd, $gpgpid) = forkreader($forkfd,
- "/usr/bin/gpg",
- "--list-packets");
+ my ($gpgfd, $gpgpid) = forkreader($forkfd, "gpg", "--list-packets");
my ($keyid, $date);
@@ -57,8 +55,7 @@ sub getkeyfromfd {
sub getkeynamefromid {
my $keyid = shift @_;
- my ($gpgfd, $gpgpid) = forkreader(undef, "/usr/bin/gpg",
- "--list-keys", $keyid);
+ my ($gpgfd, $gpgpid) = forkreader(undef, "gpg", "--list-keys", $keyid);
my $line = <$gpgfd>;
chomp $line;
Bug#1003303: debsigs: Implement the -g/--gpgopts option
Package: debsigs
Version: 0.1.25
Severity: normal
Tags: patch
Dear Maintainer,
The debsigs utility has scaffolding to support a -g/--gpgopts option but
it is not actually used. Attached is a patch to pass options specified
via -g/--gpgopts to gpg when signing. Multiple options may be specified,
separated by commas.
- todd
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debsigs depends on:
ii binutils 2.35.2-2
ii gnupg 2.2.27-2
ii perl 5.32.1-4+deb11u2
Versions of packages debsigs recommends:
ii debsig-verify 0.23+b2
debsigs suggests no packages.
-- no debconf information
commit 5311625df0d485e16fd674b452c5ecf2b0df160f
Author: Todd C. Miller
Date: Mon Sep 27 08:37:28 2021 -0600
Pass options from -g/--gpgops to gpg when signing.
Multiple options may be specified, separated by commas.
diff --git a/debsigs b/debsigs
index 25b5d44..c789681 100644
--- a/debsigs
+++ b/debsigs
@@ -105,6 +105,10 @@ sub cmd_sign($) {
my @cmdline = ("gpg", "--openpgp", "--detach-sign");
+ if ($gpgopts) {
+push (@cmdline, split(/,/, $gpgopts));
+ }
+
if ($key) {
push (@cmdline, "--default-key", $key);
}
Bug#988369: debsigs --verify not implemented
I have implemented verify mode. There is a merge request at GitLab: https://gitlab.com/debsigs/debsigs/-/merge_requests/5 - todd
Bug#734752: sudo, pam_limits, users with same UID
This has been fixed in sudo 1.9.0: https://www.sudo.ws/repos/sudo/rev/b45608f29a02
Bug#571621: sudoers grammar doesn't show that sudoedit takes an argument
In sudo 1.9.0, the sudoers grammar in the manual now indicates that "sudoedit" requires one or more arguments. - todd
Bug#669687: sudo does not call pam_end on authorization failure
Sudo 1.9.0 includes a fix for this: www.sudo.ws/repos/sudo/rev/98cb9d98f547
Bug#805833: listpw
This was fixed in sudo 1.8.20. - todd
Bug#783582: sudo german translation typo
This was fixed in the following commit on 2014-09-17: https://www.sudo.ws/repos/sudo/rev/588c41d2eab5
Bug#942680: [Pkg-shadow-devel] Bug#942680: passwd: vipw does not resume properly when suspended
On Sat, 26 Oct 2019 07:49:33 -0500, "Serge E. Hallyn" wrote: > second option sounds nicer but sure is a lot more code. So I'm > leaning towards the first. Do you mind creating a github issue > at github.com/shadow-maint/shadow for this, or would you prefer that > I do it? I opened a github issue and attached the patches: https://github.com/shadow-maint/shadow/issues/185 - todd
Bug#942680: passwd: vipw does not resume properly when suspended
Package: passwd
Version: 1:4.5-1.1
Severity: normal
Tags: patch
Dear Maintainer,
* What led up to the situation?
If vipw is suspended (e.g. via control-Z) and then resumed, it
often gets immediately suspended. This is easier to reproduce
on a multi-core system.
* What exactly did you do (or not do) that was effective (or
ineffective)?
root@buster:~# /usr/sbin/vipw
[1]+ Stopped /usr/sbin/vipw
root@buster:~# fg
/usr/sbin/vipw
[1]+ Stopped /usr/sbin/vipw
root@buster:~# fg
[vipw resumes on the second fg]
The problem is that vipw forks a child process and calls waitpid()
with the WUNTRACED flag. When the child process (running the editor)
is suspended, the parent sends itself SIGSTOP to suspend the main vipw
process. However, because the main vipw is in the same process group
as the editor which received the ^Z, the kernel already sent the
main vipw SIGTSTP.
If the main vipw receives SIGTSTP before the child, it will be
suspended and then, once resumed, will proceed to suspend itself
again.
There are two main ways to fix this. I've included patches for
each approach.
1) Don't pass the WUNTRACED flag to waitpid() in vipw.c and
just assume the main vipw will receive a stop signal from
the kernel. This is the simplest fix and works fine for
stop signals generated due to ^Z. However, if someone sends
SIGSTOP to the vipw child process via the kill command, the
parent vipw will not notice.
--- vipw.c.orig 2019-10-18 16:19:15.673956247 -0600
+++ vipw.c.simple_fix 2019-10-18 16:43:04.265583507 -0600
@@ -325,16 +325,9 @@
}
for (;;) {
- pid = waitpid (pid, &status, WUNTRACED);
- if ((pid != -1) && (WIFSTOPPED (status) != 0)) {
- /* The child (editor) was suspended.
-* Suspend vipw. */
- kill (getpid (), SIGSTOP);
- /* wake child when resumed */
- kill (pid, SIGCONT);
- } else {
+ pid = waitpid (pid, &status, 0);
+ if (pid != -1 || errno != EINTR)
break;
- }
}
if (-1 == pid) {
2) The other option is to run the child process in its own process
group as the foregroup process group. That way, control-Z will
only affect the child process and the parent can use the existing
logic to suspend the parent.
--- vipw.c.orig 2019-10-18 16:19:15.673956247 -0600
+++ vipw.c.pgrp_fix 2019-10-19 12:55:50.526591299 -0600
@@ -206,6 +206,8 @@
struct stat st1, st2;
int status;
FILE *f;
+ pid_t orig_pgrp, editor_pgrp = -1;
+ sigset_t mask, omask;
/* FIXME: the following should have variable sizes */
char filebackup[1024], fileedit[1024];
char *to_rename;
@@ -293,6 +295,8 @@
editor = DEFAULT_EDITOR;
}
+ orig_pgrp = tcgetpgrp(STDIN_FILENO);
+
pid = fork ();
if (-1 == pid) {
vipwexit ("fork", 1, 1);
@@ -302,6 +306,14 @@
char *buf;
int status;
+ /* Wait for parent to make us the foreground pgrp. */
+ if (orig_pgrp != -1) {
+ pid = getpid();
+ setpgid(0, 0);
+ while (tcgetpgrp(STDIN_FILENO) != pid)
+ continue;
+ }
+
buf = (char *) malloc (strlen (editor) + strlen (fileedit) + 2);
snprintf (buf, strlen (editor) + strlen (fileedit) + 2,
"%s %s", editor, fileedit);
@@ -324,19 +336,50 @@
}
}
+ /* Run child in a new pgrp and make it the foreground pgrp. */
+ if (orig_pgrp != -1) {
+ setpgid(pid, pid);
+ tcsetpgrp(STDIN_FILENO, pid);
+
+ /* Avoid SIGTTOU when changing foreground pgrp below. */
+ sigemptyset(&mask);
+ sigaddset(&mask, SIGTTOU);
+ sigprocmask(SIG_BLOCK, &mask, &omask);
+ }
+
for (;;) {
pid = waitpid (pid, &status, WUNTRACED);
if ((pid != -1) && (WIFSTOPPED (status) != 0)) {
/* The child (editor) was suspended.
-* Suspend vipw. */
+* Restore terminal pgrp and suspend vipw. */
+ if (orig_pgrp != -1) {
+ editor_pgrp = tcgetpgrp(STDIN_FILENO);
+ if (editor_pgrp == -1) {
+ fprintf (stderr, "%s: %s: %s", Prog,
+"tcgetpgrp", strerror (errno));
+ }
+ if (tcsetpgrp(STDIN_F
Bug#640671: sudoers gid: Operation not permitted
It looks like the root of the problem is in libgcrypt, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566351 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640671: sudoers gid: Operation not permitted
This bug is being tracked at: http://www.gratisoft.us/bugzilla/show_bug.cgi?id=511 The problem is that ldap_initialize() is modifying the effective uid. Before the call to ldap_start_tls_s(), the euid is 0, aftter ldap_start_tls_s(), the effective and saved uids are the same as the real uid. Because of this, sudo is unable to change the uid or gid later on. I've added a workaround for sudo 1.8.3 but this really seems like an LDAP bug in Debian. The current release candidate, 1.8.3rc4 contains the workaround: ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.8.3rc4.tar.gz There are also Debian packages of 1.8.3rc4 for testing, see: ftp://ftp.sudo.ws/pub/sudo/beta/packages/Debian/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#404256: "sudo -k" and "sudo -K" should ignore timestamp
This bug was fixed in sudo 1.7.4p1. - todd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589585: sudo: -v cannot be combined with -n
This will be fixed in sudo 1.7.8. The problem does not manifest in the sudo 1.8.x branch. - todd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614728: sudo: unsafe SIGCHLD catching code
This was fixed in sudo 1.7.5; sudo now uses the "self pipe trick" which solves both problems. - todd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631268: sudo-ldap does not dereference aliases
Sudo does its own ldap.conf parsing and does not use the values preloaded by the OpenLDAP libraries since that also reads $HOME/.ldaprc and ./ldaprc. The actual problem is that sudo doesn't recognize the DEREF setting in ldap.conf. This will be fixed in sudo 1.8.3. Very old versions of sudo did not disable OpenLDAP's parsing of ldap.conf which is why it used to work. - todd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640304: sudo received signal SIGBUS, Bus error
A bus error is usually an alignment problem. I can see how this could happen on 64-bit machines with strict alignment requirements (such as sparc64). The following patch fixes the problem for me. It will be part of a sudo 1.8.2p1 release. - todd diff -r d161b82321da plugins/sudoers/pwutil.c --- a/plugins/sudoers/pwutil.c Thu Sep 15 19:56:34 2011 -0400 +++ b/plugins/sudoers/pwutil.c Fri Sep 16 08:19:18 2011 -0400 @@ -508,16 +533,16 @@ /* * Copy in group list and make pointers relative to space - * at the end of the buffer. Note that the gids array must come + * at the end of the buffer. Note that the groups array must come * immediately after struct group to guarantee proper alignment. */ grlist = (struct group_list *)cp; zero_bytes(grlist, sizeof(struct group_list)); cp += sizeof(struct group_list); +grlist->groups = (char **)cp; +cp += sizeof(char *) * ngids; grlist->gids = (gid_t *)cp; cp += sizeof(gid_t) * ngids; -grlist->groups = (char **)cp; -cp += sizeof(char *) * ngids; /* Set key and datum. */ memcpy(cp, user, nsize); -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462445: sudoers bugs from debian
In message <[EMAIL PROTECTED]> so spake Didier Raboud (didier): > I have a bug that I think is similar to that one. > > While using libpam-fprint with this in /etc/pam.d/common-auth > > authsufficient pam_fprint.so > authrequiredpam_unix.so nullok_secure > > This is what I get: > > [EMAIL PROTECTED]:~$ sudo -k > [EMAIL PROTECTED]:~$ sudo echo "1" > Scan right index finger on UPEK TouchStrip > > 1 > [EMAIL PROTECTED]:~$ sudo echo "1" > Erreur de segmentation What version of sudo are you testing? Can you try with 1.6.9p15? - todd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469526: [sudo-users] Bug#469526: Sudo: Support 'mailfrom' variable in /etc/sudoers.
In message <[EMAIL PROTECTED]> so spake Justin Pryzby (justinpryzby): > The following feature request was received from a Debian user. > > http://bugs.debian.org./469526 > > > The sudo() configuration file /etc/sudoers should accept a "mailfrom" > > variable to specify the "From:" header for warning and error mail > > generated by sudo(). Sudo already supports the "mailto" and "mailsub" > > variables. That's simple enough to implement, I'll add it to the sudo 1.7 cvs tree. - todd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
