Re: doas: improve error message
On 2020-10-08 16:39, Klemens Nanni wrote: On Thu, Oct 08, 2020 at 04:23:53PM -0700, Jordan Geoghegan wrote: This improved error message would have been useful a few months ago where I had a number of end-users of one of my scripts get confused due to the cryptic error messages spit out by doas. The diff does not change behaviour or output for end-users on the command line; instead it changes syslog messages which by default are only readable by root. As admin going through logs of multiple hosts (in a centralised place) the proposed change clarifies that whatever was TRIED to be executed never actually DID execute. Hi Klemens and Theo, Yes, I'm aware it was related to syslog output. The end-user situation I mentioned involved a script run via cron job and folks were getting confused by weird messages in their syslog due to using the script wrong. Regards, Jordan
Re: doas: improve error message
On 2020-10-09, Klemens Nanni wrote: > In case `cmd' and `args' in doas.conf(5) do not match, the generated > log message is unclear and might be read as if the command executed but > failed, i.e. returned non-zero: > > # cat /etc/doas.conf > permit nopass kn cmd echo args foo > $ doas echo foo > foo > $ doas echo bar > doas: Operation not permitted > > The corresponding syslog(3) messages from /var/log/secure: > > Oct 9 01:05:14 eru doas: kn ran command echo foo as root from /home/kn > Oct 9 01:05:20 eru doas: failed command for kn: echo bar > > The following reads unambiguous and better matches the EPERM wording: > > Oct 9 01:05:20 eru doas: command not permitted for kn: echo bar ok, i think that wording was just copy/paste.
Re: doas: improve error message
Klemens Nanni wrote: > The diff does not change behaviour or output for end-users on the > command line; instead it changes syslog messages which by default are > only readable by root. ^ That's the key detail for me, as it means no additional information is being exposed. ok deraadt
Re: doas: improve error message
On Thu, Oct 08, 2020 at 04:23:53PM -0700, Jordan Geoghegan wrote: > This improved error message would have been useful a few months ago where I > had a number of end-users of one of my scripts get confused due to the > cryptic error messages spit out by doas. The diff does not change behaviour or output for end-users on the command line; instead it changes syslog messages which by default are only readable by root. As admin going through logs of multiple hosts (in a centralised place) the proposed change clarifies that whatever was TRIED to be executed never actually DID execute.
Re: doas: improve error message
Hi Klemens,
I'm not a dev, so I can't give you an OK, but I just wanted to say that
I certainly support this change.
This improved error message would have been useful a few months ago
where I had a number of end-users of one of my scripts get confused due
to the cryptic error messages spit out by doas.
Regards,
Jordan
On 2020-10-08 16:09, Klemens Nanni wrote:
In case `cmd' and `args' in doas.conf(5) do not match, the generated
log message is unclear and might be read as if the command executed but
failed, i.e. returned non-zero:
# cat /etc/doas.conf
permit nopass kn cmd echo args foo
$ doas echo foo
foo
$ doas echo bar
doas: Operation not permitted
The corresponding syslog(3) messages from /var/log/secure:
Oct 9 01:05:14 eru doas: kn ran command echo foo as root from /home/kn
Oct 9 01:05:20 eru doas: failed command for kn: echo bar
The following reads unambiguous and better matches the EPERM wording:
Oct 9 01:05:20 eru doas: command not permitted for kn: echo bar
Feedback? OK?
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.82
diff -u -p -r1.82 doas.c
--- doas.c 18 Oct 2019 17:15:45 - 1.82
+++ doas.c 8 Oct 2020 22:59:45 -
@@ -396,7 +396,7 @@ main(int argc, char **argv)
if (!permit(uid, groups, ngroups, , target, cmd,
(const char **)argv + 1)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
- "failed command for %s: %s", mypw->pw_name, cmdline);
+ "command not permitted for %s: %s", mypw->pw_name, cmdline);
errc(1, EPERM, NULL);
}
doas: improve error message
In case `cmd' and `args' in doas.conf(5) do not match, the generated
log message is unclear and might be read as if the command executed but
failed, i.e. returned non-zero:
# cat /etc/doas.conf
permit nopass kn cmd echo args foo
$ doas echo foo
foo
$ doas echo bar
doas: Operation not permitted
The corresponding syslog(3) messages from /var/log/secure:
Oct 9 01:05:14 eru doas: kn ran command echo foo as root from /home/kn
Oct 9 01:05:20 eru doas: failed command for kn: echo bar
The following reads unambiguous and better matches the EPERM wording:
Oct 9 01:05:20 eru doas: command not permitted for kn: echo bar
Feedback? OK?
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.82
diff -u -p -r1.82 doas.c
--- doas.c 18 Oct 2019 17:15:45 - 1.82
+++ doas.c 8 Oct 2020 22:59:45 -
@@ -396,7 +396,7 @@ main(int argc, char **argv)
if (!permit(uid, groups, ngroups, , target, cmd,
(const char **)argv + 1)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE,
- "failed command for %s: %s", mypw->pw_name, cmdline);
+ "command not permitted for %s: %s", mypw->pw_name, cmdline);
errc(1, EPERM, NULL);
}
Re: ssh-keygen: generate ed25519 keys by default
On 2020/10/08 15:40, Christian Weisgerber wrote: > At this point, I don't know how many SSH servers are still out there > that don't handle Ed25519. I still have an ECDSA key somewhere > that I use to log into a machine that still runs... "OpenSSH_6.0p1 > Debian-4+deb7u7, OpenSSL 1.0.1t 3 May 2016". There is a lot of > networking equipment that allows uploading of a user key for SSH > login but may include a comically obsolete version of OpenSSH or > some alternative implementation that doesn't do Ed25519. I don't think that's a show-stopper, people using such equipment likely already need to do non-default things to have OpenSSH connect to it, My typical config for connecting to switches, including some current models running latest available firmware, looks like KexAlgorithms +diffie-hellman-group14-sha1 HostKeyAlgorithms +ssh-rsa (and I still have a few things running where I need to break out an alternative client because openssh won't talk to them at all any more..)
Lenovo X1 gen 8 touchpad interrupt: pchgpio(4)
Diff below adds a driver for the GPIO controller found on the Intel
400 Series PCH as found on (for example) the Lenovo X1 gen 8 laptop.
Since I don't have such hardware, I'd appreciate some tests on laptops
that current show:
"INT34BB" at acpi0 not configured
in their dmesg.
To test, apply the diff, and do
$ cd /usr/src/sys/arch/amd64/compiler/GENERIC.MP
$ make config
$ make
probably wise to make a backup of your old kernel before installing
the new one, just in case the driver doesn't work properly.
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.493
diff -u -p -r1.493 GENERIC
--- arch/amd64/conf/GENERIC 15 Sep 2020 18:31:14 - 1.493
+++ arch/amd64/conf/GENERIC 8 Oct 2020 20:21:54 -
@@ -65,6 +65,7 @@ aplgpio* at acpi?
bytgpio* at acpi?
chvgpio* at acpi?
glkgpio* at acpi?
+pchgpio* at acpi?
sdhc* at acpi?
acpicbkbd* at acpi?
acpials* at acpi?
Index: dev/acpi/files.acpi
===
RCS file: /cvs/src/sys/dev/acpi/files.acpi,v
retrieving revision 1.57
diff -u -p -r1.57 files.acpi
--- dev/acpi/files.acpi 15 Sep 2020 18:31:14 - 1.57
+++ dev/acpi/files.acpi 8 Oct 2020 20:21:56 -
@@ -146,6 +146,11 @@ device glkgpio
attach glkgpio at acpi
file dev/acpi/glkgpio.c glkgpio
+# Intel PCH GPIO
+device pchgpio
+attach pchgpio at acpi
+file dev/acpi/pchgpio.c pchgpio
+
# "Intel" Dollar Cove TI PMIC
device tipmic
attach tipmic at i2c
Index: dev/acpi/pchgpio.c
===
RCS file: dev/acpi/pchgpio.c
diff -N dev/acpi/pchgpio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/acpi/pchgpio.c 8 Oct 2020 20:21:56 -
@@ -0,0 +1,395 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2020 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define PCHGPIO_MAXCOM 4
+
+#define PCHGPIO_CONF_TXSTATE 0x0001
+#define PCHGPIO_CONF_RXSTATE 0x0002
+#define PCHGPIO_CONF_RXINV 0x0080
+#define PCHGPIO_CONF_RXEV_EDGE 0x0200
+#define PCHGPIO_CONF_RXEV_ZERO 0x0400
+#define PCHGPIO_CONF_RXEV_MASK 0x0600
+
+#define PCHGPIO_PADBAR 0x00c
+
+struct pchgpio_group {
+ uint8_t bar;
+ uint16_tbase;
+ uint16_tlimit;
+ uint16_toffset;
+};
+
+struct pchgpio_device {
+ uint16_tpad_own;
+ uint16_tpadcfglock;
+ uint16_thostsw_own;
+ uint16_tgpi_is;
+ uint16_tgpi_ie;
+ struct pchgpio_group *groups;
+ int ngroups;
+};
+
+struct pchgpio_match {
+ const char *hid;
+ struct pchgpio_device *device;
+};
+
+struct pchgpio_intrhand {
+ int (*ih_func)(void *);
+ void *ih_arg;
+};
+
+struct pchgpio_softc {
+ struct device sc_dev;
+ struct acpi_softc *sc_acpi;
+ struct aml_node *sc_node;
+
+ bus_space_tag_t sc_memt[PCHGPIO_MAXCOM];
+ bus_space_handle_t sc_memh[PCHGPIO_MAXCOM];
+ void *sc_ih;
+ int sc_naddr;
+
+ struct pchgpio_device *sc_device;
+ uint16_t sc_padbar[PCHGPIO_MAXCOM];
+
+ int sc_npins;
+ struct pchgpio_intrhand *sc_pin_ih;
+
+ struct acpi_gpio sc_gpio;
+};
+
+intpchgpio_match(struct device *, void *, void *);
+void pchgpio_attach(struct device *, struct device *, void *);
+
+struct cfattach pchgpio_ca = {
+ sizeof(struct pchgpio_softc), pchgpio_match, pchgpio_attach
+};
+
+struct cfdriver pchgpio_cd = {
+ NULL, "pchgpio", DV_DULL
+};
+
+const char *pchgpio_hids[] = {
+ "INT344B",
+ "INT34BB",
+ NULL
+};
+
+struct pchgpio_group spt_lp_groups[] =
+{
+ /* Community 0 */
+ { 0, 0, 23, 0 },/* GPP_A */
+ { 0, 24, 47, 32 }, /* GPP_B */
+
+ /* Community 1 */
+ { 1, 48, 71, 0 }, /* GPP_C */
+ { 1, 72, 95, 32 }, /* GPP_D */
+ { 1, 96, 119, 64 }, /* GPP_E */
+
+ /* Community 3 */
+ { 2, 120, 143, 0 },
Re: ssh-keygen: generate ed25519 keys by default
On 2020-10-08, Eldritch wrote: > With the recent change to prefer ed25519 keys on the server side [1] > (unless I misunderstood what the change does), I think generating This only changed the client's order of preference for the various server key types. If a server doesn't offer an Ed25519 key, the client will transparently fall back to one of the other types. > ed25519 keys by default with ssh-keygen makes sense at this point. > > Is there a reason not to do this? I am curious if so, as there's no > discussion on this matter that I could find. Those are mostly user keys. What happens if you upload an Ed25519 public user key to a server that doesn't handle this key type? It won't work. And you're not likely to be presented with a helpful error message. It just doesn't work. At this point, I don't know how many SSH servers are still out there that don't handle Ed25519. I still have an ECDSA key somewhere that I use to log into a machine that still runs... "OpenSSH_6.0p1 Debian-4+deb7u7, OpenSSL 1.0.1t 3 May 2016". There is a lot of networking equipment that allows uploading of a user key for SSH login but may include a comically obsolete version of OpenSSH or some alternative implementation that doesn't do Ed25519. So... is it the right time yet? I don't know, and it's certainly not my decision, but I think that's the background. > --- ssh-keygen.c 9 Sep 2020 03:08:01 - 1.420 > +++ ssh-keygen.c 8 Oct 2020 08:21:37 - That's at least missing a corresponding change to the man page. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: /etc/daily: use find -delete
On Thu, Oct 08, 2020 at 05:32:15AM -0600, Todd C. Miller wrote:
> We can use find's built-in -delete primary to remove old /tmp files
> and directories. This is somewhat less error-prone than execing
> rm or rmdir.
>
OK denis@
> - todd
>
> Index: etc/daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.93
> diff -u -p -u -r1.93 daily
> --- etc/daily 9 Sep 2019 20:02:26 - 1.93
> +++ etc/daily 22 Aug 2020 01:21:16 -
> @@ -50,17 +50,17 @@ if [ -d /tmp -a ! -L /tmp ]; then
> find -x . \
> \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
> -o -path './tmux-*' \) \
> - -prune -o -type f -atime +7 -execdir rm -f -- {} \; 2>/dev/null
> + -prune -o -type f -atime +7 -delete 2>/dev/null
> find -x . -type d -mtime +1 ! -path ./vi.recover ! -path ./.X11-unix \
> ! -path ./.ICE-unix ! -name . \
> - -execdir rmdir -- {} \; >/dev/null 2>&1; }
> + -delete >/dev/null 2>&1; }
> fi
>
> # Additional junk directory cleanup would go like this:
> #if [ -d /scratch -a ! -L /scratch ]; then
> #cd /scratch && {
> -#find . ! -name . -atime +1 -execdir rm -f -- {} \;
> -#find . ! -name . -type d -mtime +1 -execdir rmdir -- {} \; \
> +#find . ! -name . -atime +1 -delete
> +#find . ! -name . -type d -mtime +1 -delete \
> #>/dev/null 2>&1; }
> #fi
>
>
/etc/daily: use find -delete
We can use find's built-in -delete primary to remove old /tmp files
and directories. This is somewhat less error-prone than execing
rm or rmdir.
- todd
Index: etc/daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.93
diff -u -p -u -r1.93 daily
--- etc/daily 9 Sep 2019 20:02:26 - 1.93
+++ etc/daily 22 Aug 2020 01:21:16 -
@@ -50,17 +50,17 @@ if [ -d /tmp -a ! -L /tmp ]; then
find -x . \
\( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
-o -path './tmux-*' \) \
- -prune -o -type f -atime +7 -execdir rm -f -- {} \; 2>/dev/null
+ -prune -o -type f -atime +7 -delete 2>/dev/null
find -x . -type d -mtime +1 ! -path ./vi.recover ! -path ./.X11-unix \
! -path ./.ICE-unix ! -name . \
- -execdir rmdir -- {} \; >/dev/null 2>&1; }
+ -delete >/dev/null 2>&1; }
fi
# Additional junk directory cleanup would go like this:
#if [ -d /scratch -a ! -L /scratch ]; then
# cd /scratch && {
-# find . ! -name . -atime +1 -execdir rm -f -- {} \;
-# find . ! -name . -type d -mtime +1 -execdir rmdir -- {} \; \
+# find . ! -name . -atime +1 -delete
+# find . ! -name . -type d -mtime +1 -delete \
# >/dev/null 2>&1; }
#fi
ssh-keygen: generate ed25519 keys by default
With the recent change to prefer ed25519 keys on the server side [1] (unless I misunderstood what the change does), I think generating ed25519 keys by default with ssh-keygen makes sense at this point. Many users prefer the algorithm for its speed, small key size, lack of trust in OpenSSL or RSA, etc. Is there a reason not to do this? I am curious if so, as there's no discussion on this matter that I could find. [1] https://marc.info/?l=openbsd-cvs=160169852214927=2 Index: ssh-keygen.c === RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v retrieving revision 1.420 diff -u -p -r1.420 ssh-keygen.c --- ssh-keygen.c9 Sep 2020 03:08:01 - 1.420 +++ ssh-keygen.c8 Oct 2020 08:21:37 - @@ -60,11 +60,7 @@ #include "ssh-pkcs11.h" #endif -#ifdef WITH_OPENSSL -# define DEFAULT_KEY_TYPE_NAME "rsa" -#else -# define DEFAULT_KEY_TYPE_NAME "ed25519" -#endif +#define DEFAULT_KEY_TYPE_NAME "ed25519" /* * Default number of bits in the RSA, DSA and ECDSA keys. These value can be
