ldapd adjust fatal message
I had an issue with some certs and noticed that fatal() is used where
errno has no meaning. This message should use fatalx().
OK?
--
:wq Claudio
Index: ldape.c
===
RCS file: /cvs/src/usr.sbin/ldapd/ldape.c,v
retrieving revision 1.36
diff -u -p -r1.36 ldape.c
--- ldape.c 19 Dec 2021 12:19:31 - 1.36
+++ ldape.c 26 Feb 2023 13:38:37 -
@@ -433,7 +433,7 @@ ldape(int debug, int verbose, char *csoc
if (tls_configure(l->tls, l->ssl->config)) {
log_warnx("ldape: %s", tls_error(l->tls));
- fatal("ldape: couldn't configure tls");
+ fatalx("ldape: couldn't configure tls");
}
}
}
Re: malloc: change chunk sizes to be multiple of 16 instead of power of 2
On Wed, Mar 01, 2023 at 08:49:56AM +0100, Theo Buehler wrote:
> On Wed, Mar 01, 2023 at 08:39:08AM +0100, Otto Moerbeek wrote:
> > On Wed, Mar 01, 2023 at 08:31:47AM +0100, Theo Buehler wrote:
> >
> > > On Tue, Feb 28, 2023 at 05:52:28PM +0100, Otto Moerbeek wrote:
> > > > Second iteration.
> > > >
> > > > Gain back performance by allocation chunk_info pages in a bundle, and
> > > > use less buckets is !malloc option S. The chunk sizes used are 16, 32,
> > > > 48, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, 448, 512, 640,
> > > > 768, 896, 1024, 1280, 1536, 1792, 2048 (and a few more for sparc84
> > > > with it's 8k sized pages and loongson with it's 16k pages).
> > > >
> > > > If malloc option S (or rather cache size 0) is used we use strict
> > > > multiple of 16 buckets, to get as many buckets as possible.
> > > >
> > > > See the find_bucket() and bin_of() functions. Thanks to Tony Finch for
> > > > pointing me to code to compute nice bucket sizes.
> > > >
> > > > I think this is ready for review and wide testing.
> > >
> > > Two vala-based ports, graphics/birdfont and productivity/minder, run out
> > > of memory when attempting to build them with this diff (and its previous
> > > version) on both amd64 and arm64:
> > >
> > > ***MEMORY-ERROR***: valac[93681]: GSlice: failed to allocate 2032 bytes
> > > (alignment: 2048): Cannot allocate memory
> >
> > Thanks, this smells like a bug in the aligned mem case.
> >
> > + pof2 = 1 << MALLOC_MINSIZE;
> >
> > should be
> >
> > + pof2 = MALLOC_MINSIZE;
> >
> > By the looks of it. I'll get back to this.
>
> I can confirm that changing this fixes this issue with both ports on
> amd64 and arm64.
So here's the dif with the fix.
-Otto
Index: stdlib/malloc.c
===
RCS file: /home/cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.277
diff -u -p -r1.277 malloc.c
--- stdlib/malloc.c 27 Feb 2023 06:47:54 - 1.277
+++ stdlib/malloc.c 1 Mar 2023 09:14:24 -
@@ -67,6 +67,11 @@
#define MALLOC_CHUNK_LISTS 4
#define CHUNK_CHECK_LENGTH 32
+#define B2SIZE(b) ((b) * MALLOC_MINSIZE)
+#define B2ALLOC(b) ((b) == 0 ? MALLOC_MINSIZE : \
+ (b) * MALLOC_MINSIZE)
+#define BUCKETS(MALLOC_MAXCHUNK / MALLOC_MINSIZE)
+
/*
* We move allocations between half a page and a whole page towards the end,
* subject to alignment constraints. This is the extra headroom we allow.
@@ -144,9 +149,9 @@ struct dir_info {
int mutex;
int malloc_mt; /* multi-threaded mode? */
/* lists of free chunk info structs */
- struct chunk_head chunk_info_list[MALLOC_MAXSHIFT + 1];
+ struct chunk_head chunk_info_list[BUCKETS + 1];
/* lists of chunks with free slots */
- struct chunk_head chunk_dir[MALLOC_MAXSHIFT + 1][MALLOC_CHUNK_LISTS];
+ struct chunk_head chunk_dir[BUCKETS + 1][MALLOC_CHUNK_LISTS];
/* delayed free chunk slots */
void *delayed_chunks[MALLOC_DELAYED_CHUNK_MASK + 1];
u_char rbytes[32]; /* random bytes */
@@ -155,6 +160,8 @@ struct dir_info {
size_t bigcache_used;
size_t bigcache_size;
struct bigcache *bigcache;
+ void *chunk_pages;
+ size_t chunk_pages_used;
#ifdef MALLOC_STATS
size_t inserts;
size_t insert_collisions;
@@ -195,8 +202,7 @@ struct chunk_info {
LIST_ENTRY(chunk_info) entries;
void *page; /* pointer to the page */
u_short canary;
- u_short size; /* size of this page's chunks */
- u_short shift; /* how far to shift for this size */
+ u_short bucket;
u_short free; /* how many free chunks */
u_short total; /* how many chunks */
u_short offset; /* requested size table offset */
@@ -247,11 +253,11 @@ static void malloc_exit(void);
#endif
/* low bits of r->p determine size: 0 means >= page size and r->size holding
- * real size, otherwise low bits are a shift count, or 1 for malloc(0)
+ * real size, otherwise low bits is the bucket + 1
*/
#define REALSIZE(sz, r)\
(sz) = (uintptr_t)(r)->p & MALLOC_PAGEMASK, \
- (sz) = ((sz) == 0 ? (r)->size : ((sz) == 1 ? 0 : (1 << ((sz)-1
+ (sz) = ((sz) == 0 ? (r)->size : B2SIZE((sz) - 1))
static inline void
_MALLOC_LEAVE(struct dir_info *d)
@@ -502,7 +508,7 @@ omalloc_poolinit(struct dir_info *d, int
d->r = NULL;
d->rbytesused = sizeof(d->rbytes);
d->regions_free = d->regions_total = 0;
- for (i = 0; i <= MALLOC_MAXSHIFT; i++) {
+ for (i = 0; i <= BUCKETS; i++) {
LIST_INIT(&d->c
Re: kernel: don't jump ticks, jiffies during boot
On Mon, Feb 27, 2023 at 08:48:53PM -0600, Scott Cheloha wrote:
> On Tue, Feb 28, 2023 at 01:01:32PM +1100, Jonathan Gray wrote:
> > On Mon, Feb 27, 2023 at 06:26:00PM -0600, Scott Cheloha wrote:
> > > On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote:
> > > > On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote:
> > > > > ticks and jiffies start at zero. During boot in initclocks(), we
> > > > > reset them:
> > > > >
> > > > > /* sys/kern/kern_clock.c */
> > > > >
> > > > > 89int ticks;
> > > > > 90static int psdiv, pscnt;/* prof => stat
> > > > > divider */
> > > > > 91int psratio;/* ratio: prof
> > > > > / stat */
> > > > > 92
> > > > > 93volatile unsigned long jiffies; /* XXX Linux
> > > > > API for drm(4) */
> > > > > 94
> > > > > 95/*
> > > > > 96 * Initialize clock frequencies and start both clocks
> > > > > running.
> > > > > 97 */
> > > > > 98void
> > > > > 99initclocks(void)
> > > > >100{
> > > > >101ticks = INT_MAX - (15 * 60 * hz);
> > > > >102jiffies = ULONG_MAX - (10 * 60 * hz);
> > > > >103
> > > > >104/* [... ] */
> > > > >
> > > > > The idea here (committed by dlg@) is sound. We reset ticks and
> > > > > jiffies to near-rollover values to catch buggy code misusing them.
> > > > >
> > > > > But! That jump from zero to whatever violates valid assumptions made
> > > > > by correct code, too.
> > > >
> > > > Assumptions made by what code? Does it exist in the tree?
> > >
> > > First, even if the code did not exist, wouldn't it be simpler to not
> > > do the jump? No?
> >
> > There are enough problems to fix without chasing ones that
> > don't exist.
> >
> > > Second, with rare exception, all kernel code using ticks/jiffies
> > > assumes ticks/jiffies does not advance more than once every 1/hz
> > > seconds on average.
> > >
> > > In timeout_add(9), we assign an absolute expiration time relative
> > > to the current value of ticks. Code calling timeout_add(9) before
> > > initclocks() cannot account for the jump in initclocks().
> >
> > What code calling timeout_add() before initclocks()?
>
> I count 8 calls on my laptop:
>
> [...]
>
> Jumping ticks/jiffies as we do in initclocks() violates assumptions
> about how ticks/jiffies work. If we initialize ticks/jiffies to
> values near rollover we can keep the test of correct behavior intended
> by dlg's patch without surprising other code.
>
> ok?
>
> Is there a better place to put "jiffies"?
kettenis@ suggested finding a way to initialize ticks/jiffies without
moving them.
HZ is not visible outside of param.c. If we move the conditional
definition of HZ from param.c into sys/kernel.h (where hz(9) is
extern'd), kern_clock.c can use it. I don't see a more obvious place
to put HZ than sys/kernel.h.
This fixes the problem. The timeouts no longer fire early.
Can I go with this?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.106
diff -u -p -r1.106 kern_clock.c
--- kern/kern_clock.c 4 Feb 2023 19:33:03 - 1.106
+++ kern/kern_clock.c 1 Mar 2023 16:34:50 -
@@ -86,11 +86,11 @@ int stathz;
intschedhz;
intprofhz;
intprofprocs;
-intticks;
+intticks = INT_MAX - (15 * 60 * HZ);
static int psdiv, pscnt; /* prof => stat divider */
intpsratio;/* ratio: prof / stat */
-volatile unsigned long jiffies;/* XXX Linux API for drm(4) */
+volatile unsigned long jiffies = ULONG_MAX - (10 * 60 * HZ);
/*
* Initialize clock frequencies and start both clocks running.
@@ -98,9 +98,6 @@ volatile unsigned long jiffies; /* XXX
void
initclocks(void)
{
- ticks = INT_MAX - (15 * 60 * hz);
- jiffies = ULONG_MAX - (10 * 60 * hz);
-
/*
* Set divisors to 1 (normal case) and let the machine-specific
* code do its bit.
Index: sys/kernel.h
===
RCS file: /cvs/src/sys/sys/kernel.h,v
retrieving revision 1.25
diff -u -p -r1.25 kernel.h
--- sys/kernel.h13 Jan 2021 16:28:50 - 1.25
+++ sys/kernel.h1 Mar 2023 16:34:50 -
@@ -56,3 +56,7 @@ extern int hz;/* system clock's frequ
extern int stathz; /* statistics clock's frequency */
extern int profhz; /* profiling clock's frequency */
extern int lbolt; /* once a second sleep address */
+
+#ifndef HZ
+#define HZ 100
+#endif
Index: conf/param.c
===
RCS file: /cvs/src/sys/conf/param.c,v
retrieving revision 1.47
diff -u -p -r1.47 param.c
--- conf/p
Re: Authentication in OpenIKED
[from misc] > > I don't see that in the iked.conf manual. There is some reference to not > > using psk in /etc/examples/iked.conf but it's not clear whether that's > > because of the need to share a single psk with all endpoints connecting > > via the same iked.conf configuration line (certainly a problem when > > you have multiple users from unknown IPs but perhaps not if used for > > separately-configured lan-to-lan tunnels with strong randomly generated > > psks) or whether it's something else. > > We should probably remove that comment. > > I think there is actually no reason to avoid PSK in IKEv2 if both endpoints > are trusted. Of course it doesn't scale well and all security considerations > for shared WiFi passwords apply here as well, but there isn't an obvious > weakeness like the plain text passphrase being sent over the network. > Expecting people to generate X509 certificates for simple peer-to-peer setups > seems a lot worse. How about this? Show a strong psk in the example, plus the existing "win7" config is a bit strange, using 'config address' to set a fixed single address while tunnelling a subnet, so I've replaced it with a config that is probably more common in real life where the tunnel is used for all traffic (which is a bit more tricky to configure if you're new to this). Index: iked.conf === RCS file: /cvs/src/etc/examples/iked.conf,v retrieving revision 1.1 diff -u -p -r1.1 iked.conf --- iked.conf 11 Jul 2014 21:20:10 - 1.1 +++ iked.conf 1 Mar 2023 16:50:12 - @@ -6,13 +6,14 @@ #user "user1" "password123" #user "user2" "password456" -# Configuration for clients connecting with EAP authentication. +# Configuration for clients connecting with EAP authentication +# and sending all traffic over the IKEv2 tunnel. # Remember to set up a PKI, see ikectl(8) for more information. -#ikev2 "win7" passive esp \ -# from 10.1.0.0/24 to 10.2.0.0/24 \ +#ikev2 "eapclient" passive esp \ +# from any to dynamic \ # local any peer any \ # eap "mschap-v2" \ -# config address 10.2.0.1 \ +# config address 10.2.0.0/24 \ # config name-server 10.1.0.2 \ # tag "$name-$id" @@ -22,4 +23,4 @@ # from 10.5.0.0/24 to 10.1.0.0/24 \ # from 10.5.0.0/24 to 172.16.1.0/24 \ # local 192.168.1.1 peer 192.168.2.1 \ -# psk "you-should-not-use-psk-authentication!" +# psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA"
Re: Authentication in OpenIKED
On Wed, Mar 01, 2023 at 04:53:00PM +, Stuart Henderson wrote: > [from misc] > > > I don't see that in the iked.conf manual. There is some reference to not > > > using psk in /etc/examples/iked.conf but it's not clear whether that's > > > because of the need to share a single psk with all endpoints connecting > > > via the same iked.conf configuration line (certainly a problem when > > > you have multiple users from unknown IPs but perhaps not if used for > > > separately-configured lan-to-lan tunnels with strong randomly generated > > > psks) or whether it's something else. > > > > We should probably remove that comment. > > > > I think there is actually no reason to avoid PSK in IKEv2 if both endpoints > > are trusted. Of course it doesn't scale well and all security considerations > > for shared WiFi passwords apply here as well, but there isn't an obvious > > weakeness like the plain text passphrase being sent over the network. > > Expecting people to generate X509 certificates for simple peer-to-peer > > setups > > seems a lot worse. > > How about this? Show a strong psk in the example, plus the existing > "win7" config is a bit strange, using 'config address' to set a fixed > single address while tunnelling a subnet, so I've replaced it with a > config that is probably more common in real life where the tunnel is > used for all traffic (which is a bit more tricky to configure if > you're new to this). Definitly better than what we had before. Thanks! > > > Index: iked.conf > === > RCS file: /cvs/src/etc/examples/iked.conf,v > retrieving revision 1.1 > diff -u -p -r1.1 iked.conf > --- iked.conf 11 Jul 2014 21:20:10 - 1.1 > +++ iked.conf 1 Mar 2023 16:50:12 - > @@ -6,13 +6,14 @@ > #user "user1" "password123" > #user "user2" "password456" > > -# Configuration for clients connecting with EAP authentication. > +# Configuration for clients connecting with EAP authentication > +# and sending all traffic over the IKEv2 tunnel. > # Remember to set up a PKI, see ikectl(8) for more information. > -#ikev2 "win7" passive esp \ > -#from 10.1.0.0/24 to 10.2.0.0/24 \ > +#ikev2 "eapclient" passive esp \ > +#from any to dynamic \ > #local any peer any \ > #eap "mschap-v2" \ > -#config address 10.2.0.1 \ > +#config address 10.2.0.0/24 \ > #config name-server 10.1.0.2 \ > #tag "$name-$id" > > @@ -22,4 +23,4 @@ > #from 10.5.0.0/24 to 10.1.0.0/24 \ > #from 10.5.0.0/24 to 172.16.1.0/24 \ > #local 192.168.1.1 peer 192.168.2.1 \ > -#psk "you-should-not-use-psk-authentication!" > +#psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA" >
installer: handle WEP failure (bwfm)
Same diff as nov 2021 "Re: installer: prompt for WEP only if available"
https://marc.info/?l=openbsd-tech&m=163680942623448&w=2
bwfm(4) still has no WEP support and using it for installs keeps showing
Which network interface do you wish to configure? (or 'done') [bse0] bwfm0
ifconfig: SIOCS80211NWKEY: Operation not supported by device
Access point? (ESSID, 'any', list# or '?') [any] 2
Security protocol? (O)pen, (W)EP, WPA-(P)SK [O]
Silence the error and disable (W)EP as answer which cannot work.
As soon as someone fixes, no matter which driver, WEP will be offered again.
OK?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1230
diff -u -p -r1.1230 install.sub
--- install.sub 21 Feb 2023 12:56:50 - 1.1230
+++ install.sub 1 Mar 2023 17:30:38 -
@@ -1245,10 +1245,11 @@ ieee80211_scan() {
# Configure 802.11 interface $1 and append ifconfig options to hostname.if $2.
# Ask the user for the access point ESSID, the security protocol and a secret.
ieee80211_config() {
- local _if=$1 _hn=$2 _prompt _nwid _haswpa=0 _err
+ local _if=$1 _hn=$2 _prompt _nwid _haswep=0 _haswpa=0 _err
- # Reset 802.11 settings and determine wpa capability.
- ifconfig $_if -nwid -nwkey
+ # Reset 802.11 settings and determine WEP and WPA capabilities.
+ ifconfig $_if -nwid
+ ifconfig $_if -nwkey 2>/dev/null && _haswep=1
ifconfig $_if -wpa 2>/dev/null && _haswpa=1
# Empty scan cache.
@@ -1273,17 +1274,18 @@ ieee80211_config() {
# 'any' implies that only open access points are considered.
if [[ $_nwid != any ]]; then
- _prompt="Security protocol? (O)pen, (W)EP"
+ _prompt="Security protocol? (O)pen"
+ ((_haswep == 1)) && _prompt="$_prompt, (W)EP"
((_haswpa == 1)) && _prompt="$_prompt, WPA-(P)SK"
while :; do
ask_until "$_prompt" "O"
- case "$_haswpa-$resp" in
- ?-[Oo]) # No further questions
+ case "${_haswep}${_haswpa}-${resp}" in
+ ??-[Oo]) # No further questions
ifconfig $_if join "$_nwid"
quote join "$_nwid" >>$_hn
break
;;
- ?-[Ww]) ask_passphrase "WEP key?"
+ 1?-[Ww])ask_passphrase "WEP key?"
# Make sure ifconfig accepts the key.
if _err=$(ifconfig $_if join "$_nwid" nwkey
"$_passphrase" 2>&1) &&
[[ -z $_err ]]; then
@@ -1292,7 +1294,7 @@ ieee80211_config() {
fi
echo "$_err"
;;
- 1-[Pp]) ask_passphrase "WPA passphrase?"
+ ?1-[Pp])ask_passphrase "WPA passphrase?"
# Make sure ifconfig accepts the key.
if ifconfig $_if join "$_nwid" wpakey
"$_passphrase"; then
quote join "$_nwid" wpakey
"$_passphrase" >>$_hn
Disabling MULTICAST flag on an interface. Force outgoing multicast traffic to a specific interface
Hi, 1) does anyone know if there is a way to disable MULTICAST on a single interface? I don't see any option in ifconfig to do this. 2) Can outgoing multicast traffic be routed to a specific interface? I don't see any option in route. It seems that the first interface, by id, is chosen. Thanks, regards
Re: Disabling MULTICAST flag on an interface. Force outgoing multicast traffic to a specific interface
On Wed, Mar 1, 2023 at 9:58 AM Luca Di Gregorio wrote: > 1) does anyone know if there is a way to disable MULTICAST on a single > interface? > I don't see any option in ifconfig to do this. > There is not. > 2) Can outgoing multicast traffic be routed to a specific interface? I > don't see any option in route. It seems that the first interface, by id, is > chosen. > Unless you enable a multicast routing daemon, it just follows normal IP routing rules and will follow the default route if there's no better match. If you want to force it to a specific interface, just add a route for 224.0.0.0/4 pointing to that interface. (Of course, if you haven't set multicast=YES in /etc/rc.conf.local then /etc/netstart will create one of those routes itself with the 'reject' flag set to block all multicast, but presumably you've already set that correctly.) Philip Guenther
mountd: no need for critical sections
The SIGHUP handler only sets a flag these days, there is no longer
any need to block it while using the exports list.
OK?
- todd
Index: sbin/mountd/mountd.c
===
RCS file: /cvs/src/sbin/mountd/mountd.c,v
retrieving revision 1.90
diff -u -p -u -r1.90 mountd.c
--- sbin/mountd/mountd.c1 Mar 2023 23:27:46 - 1.90
+++ sbin/mountd/mountd.c1 Mar 2023 23:29:18 -
@@ -736,7 +736,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
char rpcpath[RPCMNT_PATHLEN+1], dirpath[PATH_MAX];
struct hostent *hp = NULL;
struct exportlist *ep;
- sigset_t sighup_mask;
int defset, hostset;
struct fhreturn fhr;
struct dirlist *dp;
@@ -746,8 +745,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
u_short sport;
long bad = 0;
- sigemptyset(&sighup_mask);
- sigaddset(&sighup_mask, SIGHUP);
saddr = transp->xp_raddr.sin_addr.s_addr;
sport = ntohs(transp->xp_raddr.sin_port);
switch (rqstp->rq_proc) {
@@ -792,7 +789,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
}
/* Check in the exports list */
- sigprocmask(SIG_BLOCK, &sighup_mask, NULL);
ep = bad ? NULL : ex_search(&fsb.f_fsid);
hostset = defset = 0;
if (ep && (chk_host(ep->ex_defdir, saddr, &defset, &hostset) ||
@@ -804,7 +800,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
if (!svc_sendreply(transp, xdr_long,
(caddr_t)&bad))
syslog(LOG_ERR, "Can't send reply");
- sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
return;
}
if (hostset & DP_HOSTSET)
@@ -820,7 +815,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
if (!svc_sendreply(transp, xdr_long,
(caddr_t)&bad))
syslog(LOG_ERR, "Can't send reply");
- sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
return;
}
if (!svc_sendreply(transp, xdr_fhs, (caddr_t)&fhr))
@@ -844,7 +838,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
if (bad && !svc_sendreply(transp, xdr_long, (caddr_t)&bad))
syslog(LOG_ERR, "Can't send reply");
- sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
return;
case RPCMNT_DUMP:
if (!svc_sendreply(transp, xdr_mlist, NULL))
@@ -958,11 +951,7 @@ xdr_explist(XDR *xdrsp, caddr_t cp)
{
struct exportlist *ep;
int false = 0, putdef;
- sigset_t sighup_mask;
- sigemptyset(&sighup_mask);
- sigaddset(&sighup_mask, SIGHUP);
- sigprocmask(SIG_BLOCK, &sighup_mask, NULL);
ep = exphead;
while (ep) {
putdef = 0;
@@ -973,12 +962,10 @@ xdr_explist(XDR *xdrsp, caddr_t cp)
goto errout;
ep = ep->ex_next;
}
- sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
if (!xdr_bool(xdrsp, &false))
return (0);
return (1);
errout:
- sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
return (0);
}
Re: Authentication in OpenIKED
On 3/1/23 11:53, Stuart Henderson wrote: > [from misc] >>> I don't see that in the iked.conf manual. There is some reference to not >>> using psk in /etc/examples/iked.conf but it's not clear whether that's >>> because of the need to share a single psk with all endpoints connecting >>> via the same iked.conf configuration line (certainly a problem when >>> you have multiple users from unknown IPs but perhaps not if used for >>> separately-configured lan-to-lan tunnels with strong randomly generated >>> psks) or whether it's something else. >> We should probably remove that comment. >> >> I think there is actually no reason to avoid PSK in IKEv2 if both endpoints >> are trusted. Of course it doesn't scale well and all security considerations >> for shared WiFi passwords apply here as well, but there isn't an obvious >> weakeness like the plain text passphrase being sent over the network. >> Expecting people to generate X509 certificates for simple peer-to-peer setups >> seems a lot worse. > How about this? Show a strong psk in the example, plus the existing > "win7" config is a bit strange, using 'config address' to set a fixed > single address while tunnelling a subnet, so I've replaced it with a > config that is probably more common in real life where the tunnel is > used for all traffic (which is a bit more tricky to configure if > you're new to this). Looks really good, just a bikeshedding question inlined. > > Index: iked.conf > === > RCS file: /cvs/src/etc/examples/iked.conf,v > retrieving revision 1.1 > diff -u -p -r1.1 iked.conf > --- iked.conf 11 Jul 2014 21:20:10 - 1.1 > +++ iked.conf 1 Mar 2023 16:50:12 - > @@ -6,13 +6,14 @@ > #user "user1" "password123" > #user "user2" "password456" > > -# Configuration for clients connecting with EAP authentication. > +# Configuration for clients connecting with EAP authentication > +# and sending all traffic over the IKEv2 tunnel. > # Remember to set up a PKI, see ikectl(8) for more information. Is a PKI still needed in this example config? The comment seems to imply that I need one even with PSK auth. Like PKI is an alternative, so maybe something like - Setting up a PKI is an alternative to using a PSK, see ikectl(8) for more information. > -#ikev2 "win7" passive esp \ > -#from 10.1.0.0/24 to 10.2.0.0/24 \ > +#ikev2 "eapclient" passive esp \ > +#from any to dynamic \ > #local any peer any \ > #eap "mschap-v2" \ > -#config address 10.2.0.1 \ > +#config address 10.2.0.0/24 \ > #config name-server 10.1.0.2 \ > #tag "$name-$id" > > @@ -22,4 +23,4 @@ > #from 10.5.0.0/24 to 10.1.0.0/24 \ > #from 10.5.0.0/24 to 172.16.1.0/24 \ > #local 192.168.1.1 peer 192.168.2.1 \ > -#psk "you-should-not-use-psk-authentication!" > +#psk "tyBNv13zuo3rg1WVXlaI1g1tTYNzwk962mMUYIvaLh2x8vvvyA" >
Re: mountd: no need for critical sections
01.03.2023 23:31, Todd C. Miller пишет:
> The SIGHUP handler only sets a flag these days, there is no longer
> any need to block it while using the exports list.
Makes sense.
The TERM handler also just sets a flag today, but etc/rc.d/mountd still
has `rc_stop=NO' since 2013
Do not allow stopping/restarting mountd using the rc.d(8) framework;
if there is need to send a SIGTERM to mountd(8), it should be done
manually as there is too much involved with RPC daemons to make it
automagic.
Can this be flipped so `rcctl stop mountd' works again?
>
> - todd
>
> Index: sbin/mountd/mountd.c
> ===
> RCS file: /cvs/src/sbin/mountd/mountd.c,v
> retrieving revision 1.90
> diff -u -p -u -r1.90 mountd.c
> --- sbin/mountd/mountd.c 1 Mar 2023 23:27:46 - 1.90
> +++ sbin/mountd/mountd.c 1 Mar 2023 23:29:18 -
> @@ -736,7 +736,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
> char rpcpath[RPCMNT_PATHLEN+1], dirpath[PATH_MAX];
> struct hostent *hp = NULL;
> struct exportlist *ep;
> - sigset_t sighup_mask;
> int defset, hostset;
> struct fhreturn fhr;
> struct dirlist *dp;
> @@ -746,8 +745,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
> u_short sport;
> long bad = 0;
>
> - sigemptyset(&sighup_mask);
> - sigaddset(&sighup_mask, SIGHUP);
> saddr = transp->xp_raddr.sin_addr.s_addr;
> sport = ntohs(transp->xp_raddr.sin_port);
> switch (rqstp->rq_proc) {
> @@ -792,7 +789,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
> }
>
> /* Check in the exports list */
> - sigprocmask(SIG_BLOCK, &sighup_mask, NULL);
> ep = bad ? NULL : ex_search(&fsb.f_fsid);
> hostset = defset = 0;
> if (ep && (chk_host(ep->ex_defdir, saddr, &defset, &hostset) ||
> @@ -804,7 +800,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
> if (!svc_sendreply(transp, xdr_long,
> (caddr_t)&bad))
> syslog(LOG_ERR, "Can't send reply");
> - sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
> return;
> }
> if (hostset & DP_HOSTSET)
> @@ -820,7 +815,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
> if (!svc_sendreply(transp, xdr_long,
> (caddr_t)&bad))
> syslog(LOG_ERR, "Can't send reply");
> - sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
> return;
> }
> if (!svc_sendreply(transp, xdr_fhs, (caddr_t)&fhr))
> @@ -844,7 +838,6 @@ mntsrv(struct svc_req *rqstp, SVCXPRT *t
>
> if (bad && !svc_sendreply(transp, xdr_long, (caddr_t)&bad))
> syslog(LOG_ERR, "Can't send reply");
> - sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
> return;
> case RPCMNT_DUMP:
> if (!svc_sendreply(transp, xdr_mlist, NULL))
> @@ -958,11 +951,7 @@ xdr_explist(XDR *xdrsp, caddr_t cp)
> {
> struct exportlist *ep;
> int false = 0, putdef;
> - sigset_t sighup_mask;
>
> - sigemptyset(&sighup_mask);
> - sigaddset(&sighup_mask, SIGHUP);
> - sigprocmask(SIG_BLOCK, &sighup_mask, NULL);
> ep = exphead;
> while (ep) {
> putdef = 0;
> @@ -973,12 +962,10 @@ xdr_explist(XDR *xdrsp, caddr_t cp)
> goto errout;
> ep = ep->ex_next;
> }
> - sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
> if (!xdr_bool(xdrsp, &false))
> return (0);
> return (1);
> errout:
> - sigprocmask(SIG_UNBLOCK, &sighup_mask, NULL);
> return (0);
> }
>
>
