move sndio session cookie to its own directory
Currently the session cookie is created in:
$HOME/.aucat_cookie
besides being ugly, this makes libsndio difficult to use with
unveil(2). This change is to make libsndio use:
$HOME/.sndio/cookie
instead.
OK?
Index: aucat.c
===
RCS file: /cvs/src/lib/libsndio/aucat.c,v
retrieving revision 1.71
diff -u -p -u -p -r1.71 aucat.c
--- aucat.c 9 Jan 2016 08:27:24 - 1.71
+++ aucat.c 26 Jul 2018 21:37:08 -
@@ -205,7 +205,8 @@ _aucat_wdata(struct aucat *hdl, const vo
static int
aucat_mkcookie(unsigned char *cookie)
{
-#define COOKIE_SUFFIX "/.aucat_cookie"
+#define COOKIE_DIR "/.sndio"
+#define COOKIE_SUFFIX "/.sndio/cookie"
#define TEMPL_SUFFIX "."
struct stat sb;
char *home, *path = NULL, *tmp = NULL;
@@ -264,11 +265,20 @@ bad_gen:
/*
* try to save the cookie
*/
+
if (home == NULL)
goto done;
tmp = malloc(path_len + sizeof(TEMPL_SUFFIX));
if (tmp == NULL)
goto done;
+
+ /* create ~/.sndio directory */
+ memcpy(tmp, home, home_len);
+ memcpy(tmp + home_len, COOKIE_DIR, sizeof(COOKIE_DIR));
+ if (mkdir(tmp, 0755) < 0 && errno != EEXIST)
+ goto done;
+
+ /* create cookie file in it */
memcpy(tmp, path, path_len);
memcpy(tmp + path_len, TEMPL_SUFFIX, sizeof(TEMPL_SUFFIX));
fd = mkstemp(tmp);
Index: sio_open.3
===
RCS file: /cvs/src/lib/libsndio/sio_open.3,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 sio_open.3
--- sio_open.3 3 Jan 2017 20:29:28 - 1.46
+++ sio_open.3 26 Jul 2018 21:37:09 -
@@ -690,7 +690,7 @@ promises.
and
.Va cpath
are needed to read, write or create the authentication cookie
-.Pa ~/.aucat_cookie .
+.Pa ~/.sndio/cookie .
.It
.Va rpath ,
.Va wpath ,
Index: sndio.7
===
RCS file: /cvs/src/lib/libsndio/sndio.7,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 sndio.7
--- sndio.7 7 Dec 2017 15:43:03 - 1.19
+++ sndio.7 26 Jul 2018 21:37:09 -
@@ -191,7 +191,7 @@ Users are identified by their
which is automatically generated by audio or MIDI applications
upon the first connection to the server.
The cookie is stored in
-.Pa "$HOME/.aucat_cookie"
+.Pa "$HOME/.sndio/cookie"
and contains 128 bits of raw random data.
.Pp
If a session needs to be shared between multiple users, they
Re: inteldrm: always use probed screen size for fb
On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote: > I'm hesitant to change this code. How does Linux behave on tese > machines? Does it use the invisible part of the framebuffer? Or have > they done away with actually using the kernel framebuffer completely > like some developers threatened a couple of years ago... I booted a Linux USB drive and it just shows a purple/black screen for a few seconds while the kernel loads until some text flashes for half a second (systemd?) and then X loads. When I switch back to the console, it doesn't draw off the screen. I have no idea what it's doing under the hood to figure out the resolution for the console. (I'd make a joke about Linux developers hiding all of that ugly kernel text output from users, but ironically the OpenBSD kernel wastes about 5-8 seconds during boot just printing kernel text through rasops.) > Do you have a (larger) monitor connected to your laptops when this happens? No, nothing connected. BTW this diff is in snaps.
Re: inteldrm: always use probed screen size for fb
> Date: Mon, 23 Jul 2018 13:28:40 -0500
> From: joshua stein
>
> On the 2015 MacBook Pro and the 12" MacBook, the firmware reports a
> framebuffer size of 2880x1800 but the screens are 2560x1600 and
> 2304x1440. Our console ends up drawing text off screen and the
> latest few lines can't be read.
>
> Once X loads, it probes the outputs again and uses the proper
> resolution.
>
> For the console, the outputs are already being probed but the BIOS
> resolution is only discarded if it's too small. I'd like to change
> it to discard it if it's too large as well, so it uses the actual
> resolution probed.
>
> On a machine like a server where inteldrm loads but has nothing
> connected, intel_fb is null, so this code doesn't run.
I'm hesitant to change this code. How does Linux behave on tese
machines? Does it use the invisible part of the framebuffer? Or have
they done away with actually using the kernel framebuffer completely
like some developers threatened a couple of years ago...
Do you have a (larger) monitor connected to your laptops when this happens?
Maybe the wsdisplay(4) interface code should be a bit more clever when
it initializes rasops and make sure we only use the part of the
framebuffer that is visible on all connected displays...
> Index: sys/dev/pci/drm/i915/intel_fbdev.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 intel_fbdev.c
> --- sys/dev/pci/drm/i915/intel_fbdev.c1 Jul 2017 16:14:10 -
> 1.3
> +++ sys/dev/pci/drm/i915/intel_fbdev.c23 Jul 2018 17:58:03 -
> @@ -202,10 +202,9 @@ static int intelfb_create(struct drm_fb_
> mutex_lock(>struct_mutex);
>
> if (intel_fb &&
> - (sizes->fb_width > intel_fb->base.width ||
> - sizes->fb_height > intel_fb->base.height)) {
> - DRM_DEBUG_KMS("BIOS fb too small (%dx%d), we require (%dx%d),"
> - " releasing it\n",
> + (sizes->fb_width != intel_fb->base.width ||
> + sizes->fb_height != intel_fb->base.height)) {
> + DRM_DEBUG_KMS("BIOS fb %dx%d != %dx%d, releasing it\n",
> intel_fb->base.width, intel_fb->base.height,
> sizes->fb_width, sizes->fb_height);
> drm_framebuffer_unreference(_fb->base);
>
>
smtpd: improve message parser
Hi,
The message parser was introduced for different reasons, when it
turned out that altering the incoming message was actually needed.
It is used to add required "Date" and "Message-ID" headers if missing,
to append the local domain to incomplete addresses found in "To",
"From" and "Cc" headers, and to provide basic sender masquerading.
The current implementation was a best-effort, but it has some
short-comings, especially when it comes to the handling of long lines.
So this diff provides a replacement for the whole parser, with the
following intended improvements:
- Use a more straightforward interface rather than the callback approach.
- Avoid unnecessary string copy.
- Stop using fixed-size string buffers, especially on the stack.
This is a step towards better handling of message line length in the daemon.
Please test and report success/issues.
Eric.
Index: rfc5322.c
===
RCS file: rfc5322.c
diff -N rfc5322.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ rfc5322.c 26 Jul 2018 14:40:56 -
@@ -0,0 +1,264 @@
+/* $OpenBSD: rfc5322.c,v 1.7 2016/02/04 22:35:17 eric Exp $*/
+
+/*
+ * Copyright (c) 2018 Eric Faurot
+ *
+ * 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 "rfc5322.h"
+
+struct buf {
+ char*buf;
+ size_t bufsz;
+ size_t buflen;
+ size_t bufmax;
+};
+
+static int buf_alloc(struct buf *, size_t);
+static int buf_grow(struct buf *, size_t);
+static int buf_cat(struct buf *, const char *);
+
+struct rfc5322_parser {
+ const char *line;
+ int state; /* last parser state */
+ int next; /* parser needs data */
+ int unfold;
+ const char *currhdr;
+ struct buf hdr;
+ struct buf val;
+};
+
+struct rfc5322_parser *
+rfc5322_parser_new(void)
+{
+ struct rfc5322_parser *parser;
+
+ parser = calloc(1, sizeof(*parser));
+ if (parser == NULL)
+ return NULL;
+
+ rfc5322_clear(parser);
+ parser->hdr.bufmax = 1024;
+ parser->val.bufmax = 65536;
+
+ return parser;
+}
+
+void
+rfc5322_free(struct rfc5322_parser *parser)
+{
+ free(parser->hdr.buf);
+ free(parser->val.buf);
+ free(parser);
+}
+
+void
+rfc5322_clear(struct rfc5322_parser *parser)
+{
+ parser->line = NULL;
+ parser->state = RFC5322_NONE;
+ parser->next = 0;
+ parser->hdr.buflen = 0;
+ parser->val.buflen = 0;
+}
+
+int
+rfc5322_push(struct rfc5322_parser *parser, const char *line)
+{
+ if (parser->line) {
+ errno = EALREADY;
+ return -1;
+ }
+
+ parser->line = line;
+ parser->next = 0;
+
+ return 0;
+}
+
+int
+rfc5322_unfold_header(struct rfc5322_parser *parser)
+{
+ if (parser->unfold) {
+ errno = EALREADY;
+ return -1;
+ }
+
+ if (parser->currhdr == NULL) {
+ errno = EOPNOTSUPP;
+ return -1;
+ }
+
+ if (buf_cat(>val, parser->currhdr) == -1)
+ return -1;
+
+ parser->currhdr = NULL;
+ parser->unfold = 1;
+
+ return 0;
+}
+
+static int
+_rfc5322_next(struct rfc5322_parser *parser, struct rfc5322_result *res)
+{
+ size_t len;
+ const char *pos, *line;
+
+ line = parser->line;
+
+ switch(parser->state) {
+
+ case RFC5322_HEADER_START:
+ case RFC5322_HEADER_CONT:
+ res->hdr = parser->hdr.buf;
+
+ if (line && (line[0] == ' ' || line[0] == '\t')) {
+ parser->line = NULL;
+ parser->next = 1;
+ if (parser->unfold) {
+ if (buf_cat(>val, "\n") == -1 ||
+ buf_cat(>val, line) == -1)
+ return -1;
+ }
+ res->value = line;
+ return RFC5322_HEADER_CONT;
+ }
+
+ if (parser->unfold) {
+ parser->val.buflen = 0;
+ parser->unfold = 0;
+
Re: tighten pledge(2) a little further on spamdb(8)
correct, still works only with stdio.
if/else can go away and we can just callpledge stdio unconditionally.
Index: spamdb.c
===
RCS file: /cvs/src/usr.sbin/spamdb/spamdb.c,v
retrieving revision 1.34
diff -u -p -u -r1.34 spamdb.c
--- spamdb.c29 Oct 2017 19:11:34 - 1.34
+++ spamdb.c26 Jul 2018 16:39:31 -
@@ -368,13 +368,8 @@ main(int argc, char **argv)
action ? "writing" : "reading");
}
- if (action == 0) {
- if (pledge("stdio rpath", NULL) == -1)
- err(1, "pledge");
- } else {
- if (pledge("stdio rpath wpath", NULL) == -1)
- err(1, "pledge");
- }
+ if (pledge("stdio", NULL) == -1)
+ err(1, "pledge");
switch (action) {
case 0:
On 18:02 Thu 26 Jul , Sebastien Marie wrote:
> On Thu, Jul 26, 2018 at 03:40:52PM +0100, Ricardo Mestre wrote:
> > Hi,
> >
> > After the DB is already opened we won't need to read it anymore so rpath
> > can go away, we still just need wpath in the case we are adding/removing
> > entries in the DB.
> >
>
> I am a bit unsure with spamdb code, but it seems to me that the sole
> open(2) call in the program is done by dbopen() ? and all db* functions
> (dbupdate(), dbprint(), ...) are read(2) or write(2) on the opened file
> descriptor ?
>
> 'rpath' or 'wpath' doesn't forbid read(2) or write(2) calls. They forbids
> the opening of a new descriptor with O_RD or O_WR respectively.
>
> Here, once dbopen() is called, you should be able to pledge("stdio",
> NULL), and dbupdate() should still work.
>
> please let me know if it isn't the case.
>
> >
> > Index: spamdb.c
> > ===
> > RCS file: /cvs/src/usr.sbin/spamdb/spamdb.c,v
> > retrieving revision 1.34
> > diff -u -p -u -r1.34 spamdb.c
> > --- spamdb.c29 Oct 2017 19:11:34 - 1.34
> > +++ spamdb.c26 Jul 2018 14:36:58 -
> > @@ -369,10 +369,10 @@ main(int argc, char **argv)
> > }
> >
> > if (action == 0) {
> > - if (pledge("stdio rpath", NULL) == -1)
> > + if (pledge("stdio", NULL) == -1)
> > err(1, "pledge");
> > } else {
> > - if (pledge("stdio rpath wpath", NULL) == -1)
> > + if (pledge("stdio wpath", NULL) == -1)
> > err(1, "pledge");
> > }
> >
>
> --
> Sebastien Marie
unveil(2) usage in base
This mail includes a large diff of userland which demonstrates how
unveil() will be used in base.
Additionally, some of you have probably noticed that there is an unveil
diff brewing for chrome in ports; others probably heard that unveil was
specifically designed to "also satisfy chrome's requirements". Since
chrome already does pretty good privsep and is designed for filesystem
containment on other platforms, we considered it's requirements in the
design of the mechanism.
First off, you need this kernel diff to enable unveil():
Index: sys/kern/vfs_syscalls.c
===
RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.295
diff -u -p -u -r1.295 vfs_syscalls.c
--- sys/kern/vfs_syscalls.c 22 Jul 2018 06:31:17 - 1.295
+++ sys/kern/vfs_syscalls.c 25 Jul 2018 17:28:09 -
@@ -913,9 +913,6 @@ sys_unveil(struct proc *p, void *v, regi
if (pathlen < 2)
return EINVAL;
- /* XXX unveil is disabled but returns sucess for now */
- return 0;
-
if (pathlen == 2 && pathname[0] == '/')
NDINIT(, LOOKUP, FOLLOW | LOCKLEAF | SAVENAME,
UIO_SYSSPACE, pathname, p);
And here is the userland diff, applying to about 37 programs. There will
be weaknesses and errors in here. This is not perfect yet.
I hope we can bring that list to 50 before activating unveil(). A
snapshot release may precede that also, so that we can identify fallout
easier. In anycase, there are a few known bugs in kernel side of unveil
which need fixing beforehands (nothing serious).
Enjoy.
Index: bin/ps/ps.c
===
RCS file: /cvs/src/bin/ps/ps.c,v
retrieving revision 1.71
diff -u -p -u -r1.71 ps.c
--- bin/ps/ps.c 23 Sep 2016 06:28:08 - 1.71
+++ bin/ps/ps.c 12 Jul 2018 16:18:13 -
@@ -276,6 +276,19 @@ main(int argc, char *argv[])
if (kd == NULL)
errx(1, "%s", errbuf);
+ if (unveil(_PATH_DEVDB, "r") == -1)
+ err(1, "unveil");
+ if (unveil("/dev", "r") == -1)
+ err(1, "unveil");
+ if (swapf)
+ if (unveil(swapf, "r") == -1)
+ err(1, "unveil");
+ if (nlistf)
+ if (unveil(nlistf, "r") == -1)
+ err(1, "unveil");
+ if (memf)
+ if (unveil(memf, "r") == -1)
+ err(1, "unveil");
if (pledge("stdio rpath getpw ps", NULL) == -1)
err(1, "pledge");
Index: include/login_cap.h
===
RCS file: /cvs/src/include/login_cap.h,v
retrieving revision 1.15
diff -u -p -u -r1.15 login_cap.h
--- include/login_cap.h 21 Nov 2014 05:13:44 - 1.15
+++ include/login_cap.h 12 Jul 2018 16:18:13 -
@@ -42,6 +42,7 @@
#defineLOGIN_DEFSERVICE"login"
#defineLOGIN_DEFUMASK 022
#define_PATH_LOGIN_CONF"/etc/login.conf"
+#define_PATH_AUTHPROGDIR "/usr/libexec/auth"
#define_PATH_AUTHPROG "/usr/libexec/auth/login_"
#defineLOGIN_SETGROUP 0x0001 /* Set group */
Index: libexec/comsat/comsat.c
===
RCS file: /cvs/src/libexec/comsat/comsat.c,v
retrieving revision 1.48
diff -u -p -u -r1.48 comsat.c
--- libexec/comsat/comsat.c 3 Apr 2017 17:23:39 - 1.48
+++ libexec/comsat/comsat.c 12 Jul 2018 16:18:13 -
@@ -91,6 +91,12 @@ main(int argc, char *argv[])
exit(1);
}
+ if (unveil(_PATH_MAILDIR, "r") == -1)
+ err(1, "unveil");
+ if (unveil(_PATH_UTMP, "r") == -1)
+ err(1, "unveil");
+ if (unveil("/tmp", "w") == -1)
+ err(1, "unveil");
if (pledge("stdio rpath wpath proc tty", NULL) == -1)
err(1, "pledge");
Index: libexec/fingerd/fingerd.c
===
RCS file: /cvs/src/libexec/fingerd/fingerd.c,v
retrieving revision 1.39
diff -u -p -u -r1.39 fingerd.c
--- libexec/fingerd/fingerd.c 13 Nov 2015 01:26:33 - 1.39
+++ libexec/fingerd/fingerd.c 12 Jul 2018 16:18:13 -
@@ -68,7 +68,7 @@ main(int argc, char *argv[])
char **ap, *av[ENTRIES + 1], line[8192], *lp, *hname;
char hostbuf[HOST_NAME_MAX+1];
- if (pledge("stdio inet dns proc exec", NULL) == -1)
+ if (pledge("stdio unveil inet dns proc exec", NULL) == -1)
err(1, "pledge");
prog = _PATH_FINGER;
@@ -110,6 +110,9 @@ main(int argc, char *argv[])
default:
usage();
}
+
+ if (unveil(_PATH_FINGER, "x") == -1)
+ err(1, "unveil");
if (logging) {
struct sockaddr_storage ss;
Index: libexec/getty/main.c
Re: mg(1): Ignore dirty flag on *undo* buffer
Thanks!
However, since rev 1.72 of buffer.c this is not necessary any more.
Buffers with names starting and ending with '*' are considered throw
away and have BFIGNDIRTY set in bnew().
On Sun, Jul 22, 2018 at 12:14:32PM +0200, Joachim Nilsson wrote:
> Hi guys,
>
> here's a patch to mg I did a couple of years ago to my fork[1], maybe
> it's interesting to other people as well.
>
> Best regards
> /Joachim
>
> [1]: https://github.com/troglobit/mg
>
> --
>
> From b14456674b9c78fdcabe14d802a9d7315d5a67a2 Mon Sep 17 00:00:00 2001
> From: Joachim Nilsson
> Date: Sat, 14 May 2016 15:44:40 +0200
> Subject: [PATCH] Set ignore-dirty flag on *undo* buffer
>
> Ignore return value from bclear() and set BFIGNDIRTY flag to always
> force a clear of any existing *undo* buffer.
>
> Signed-off-by: Joachim Nilsson
> ---
> undo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/undo.c b/undo.c
> index 8630b66..f85278b 100644
> --- a/undo.c
> +++ b/undo.c
> @@ -395,8 +395,8 @@ undo_dump(int f, int n)
>*/
> if ((bp = bfind("*undo*", TRUE)) == NULL)
> return (FALSE);
> - bp->b_flag |= BFREADONLY;
> - bclear(bp);
> + bp->b_flag |= BFREADONLY | BFIGNDIRTY;
> + (void)bclear(bp);
> if ((wp = popbuf(bp, WNONE)) == NULL)
> return (FALSE);
>
>
--
I'm not entirely sure you are real.
tighten pledge(2) a little further on spamdb(8)
Hi,
After the DB is already opened we won't need to read it anymore so rpath
can go away, we still just need wpath in the case we are adding/removing
entries in the DB.
OK?
Index: spamdb.c
===
RCS file: /cvs/src/usr.sbin/spamdb/spamdb.c,v
retrieving revision 1.34
diff -u -p -u -r1.34 spamdb.c
--- spamdb.c29 Oct 2017 19:11:34 - 1.34
+++ spamdb.c26 Jul 2018 14:36:58 -
@@ -369,10 +369,10 @@ main(int argc, char **argv)
}
if (action == 0) {
- if (pledge("stdio rpath", NULL) == -1)
+ if (pledge("stdio", NULL) == -1)
err(1, "pledge");
} else {
- if (pledge("stdio rpath wpath", NULL) == -1)
+ if (pledge("stdio wpath", NULL) == -1)
err(1, "pledge");
}
