Re: RLIMIT_CPU doesn't work reliably on mostly idle systems

[Scott Cheloha]

On Tue, Aug 29, 2023 at 07:15:14PM +0200, Claudio Jeker wrote:
> On Tue, Aug 29, 2023 at 01:01:10AM +, Eric Wong wrote:
> > >Synopsis: RLIMIT_CPU doesn't work reliably on mostly idle systems
> > >Category: system
> > >Environment:
> > System  : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 
> > 2023
> >  
> > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.octeon
> > Machine : octeon
> > >Description:
> > 
> > RLIMIT_CPU doesn't work reliably when few/no syscalls are made on an
> > otherwise idle system (aside from the test process using up CPU).
> > It can take 20-50s to fire SIGKILL with rlim_max=9 (and the SIGXCPU
> > from rlim_cur=1 won't even fire).
> > 
> > I can reproduce this on a private amd64 VM and also on gcc231
> > on GCC compiler farm .
> > I can't reproduce this on a busy system like gcc220 on cfarm,
> > however.
> 
> Thanks for the report. There is indeed an issue in how the CPU time is
> accounted on an idle system. The below diff is a possible fix.
> 
> In roundrobin() force a resched and therefor mi_switch() when
> SPCF_SHOULDYIELD is set. On an idle CPU mi_switch() will just do all
> accounting bits but skip the expensive cpu_switchto() since the proc
> remains the same.

This is an elegant solution.  I'm a little reluctant to add
mi_switch() overhead to a thread if *nothing* else wants to run, but
the roundrobin() quantum is massive at the moment, so it's not all
that much.  This change also fixes a couple other things.

- Runaway user threads (like a synthetic spinloop) can no longer
  keep the system from suspending.  If such threads are forced into
  mi_switch() after two ticks, sched_chooseproc() will then see
  SPCF_SHOULDHALT, etc.

- Sibling theads in a process using ITIMER_VIRTUAL or ITIMER_PROF
  are now forced to enable the itimer_update() interrupt after
  two ticks.

- Sibling threads in a process running profil(2) are now forced
  to enable the profclock() interrupt after two ticks.

For sake of discussion, an alternative approach is below.  Basically,
tweak rucheck() to account for any un-accumulated ONPROC time.  It
seems to work.

I would lean toward your change, though.  Fixing those other things is
a nice bonus.

Index: kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.78
diff -u -p -r1.78 kern_resource.c
--- kern_resource.c 29 Aug 2023 16:19:34 -  1.78
+++ kern_resource.c 29 Aug 2023 22:21:06 -
@@ -531,21 +531,32 @@ ruadd(struct rusage *ru, struct rusage *
 void
 rucheck(void *arg)
 {
+   struct timespec elapsed, now, total;
struct rlimit rlim;
struct process *pr = arg;
time_t runtime;
+   struct proc *p;
int s;
 
KERNEL_ASSERT_LOCKED();
 
SCHED_LOCK(s);
-   runtime = pr->ps_tu.tu_runtime.tv_sec;
+   nanouptime();
+   total = pr->ps_tu.tu_runtime;
+   TAILQ_FOREACH(p, >ps_threads, p_thr_link) {
+   if (p->p_stat == SONPROC) {
+   timespecsub(, >p_cpu->ci_schedstate.spc_runtime,
+   );
+   timespecadd(, , );
+   }
+   }
SCHED_UNLOCK(s);
 
mtx_enter(>ps_mtx);
rlim = pr->ps_limit->pl_rlimit[RLIMIT_CPU];
mtx_leave(>ps_mtx);
 
+   runtime = total.tv_sec;
if ((rlim_t)runtime >= rlim.rlim_cur) {
if ((rlim_t)runtime >= rlim.rlim_max) {
prsignal(pr, SIGKILL);

Re: RLIMIT_CPU doesn't work reliably on mostly idle systems

[Mark Kettenis]

> Date: Tue, 29 Aug 2023 19:15:14 +0200
> From: Claudio Jeker 
> 
> On Tue, Aug 29, 2023 at 01:01:10AM +, Eric Wong wrote:
> > >Synopsis: RLIMIT_CPU doesn't work reliably on mostly idle systems
> > >Category: system
> > >Environment:
> > System  : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 
> > 2023
> >  
> > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.octeon
> > Machine : octeon
> > >Description:
> > 
> > RLIMIT_CPU doesn't work reliably when few/no syscalls are made on an
> > otherwise idle system (aside from the test process using up CPU).
> > It can take 20-50s to fire SIGKILL with rlim_max=9 (and the SIGXCPU
> > from rlim_cur=1 won't even fire).
> > 
> > I can reproduce this on a private amd64 VM and also on gcc231
> > on GCC compiler farm .
> > I can't reproduce this on a busy system like gcc220 on cfarm,
> > however.
> 
> Thanks for the report. There is indeed an issue in how the CPU time is
> accounted on an idle system. The below diff is a possible fix.
> 
> In roundrobin() force a resched and therefor mi_switch() when
> SPCF_SHOULDYIELD is set. On an idle CPU mi_switch() will just do all
> accounting bits but skip the expensive cpu_switchto() since the proc
> remains the same.

A bit of a hack, but probably better than trying to account for
spc_runtime at the point where we check the limit.

Also this will call smr_idle() sooner, which may help speed up smr?

ok kettenis@

> Index: kern/sched_bsd.c
> ===
> RCS file: /cvs/src/sys/kern/sched_bsd.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 sched_bsd.c
> --- kern/sched_bsd.c  29 Aug 2023 16:19:34 -  1.84
> +++ kern/sched_bsd.c  29 Aug 2023 16:20:03 -
> @@ -106,7 +106,7 @@ roundrobin(struct clockintr *cl, void *c
>   }
>   }
>  
> - if (spc->spc_nrun)
> + if (spc->spc_nrun || spc->spc_schedflags & SPCF_SHOULDYIELD)
>   need_resched(ci);
>  }
>  
> 
> 

Re: RLIMIT_CPU doesn't work reliably on mostly idle systems

[Claudio Jeker]

On Tue, Aug 29, 2023 at 01:01:10AM +, Eric Wong wrote:
> >Synopsis: RLIMIT_CPU doesn't work reliably on mostly idle systems
> >Category: system
> >Environment:
>   System  : OpenBSD 7.3
>   Details : OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT 
> 2023
>
> dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.octeon
>   Machine : octeon
> >Description:
> 
> RLIMIT_CPU doesn't work reliably when few/no syscalls are made on an
> otherwise idle system (aside from the test process using up CPU).
> It can take 20-50s to fire SIGKILL with rlim_max=9 (and the SIGXCPU
> from rlim_cur=1 won't even fire).
> 
> I can reproduce this on a private amd64 VM and also on gcc231
> on GCC compiler farm .
> I can't reproduce this on a busy system like gcc220 on cfarm,
> however.

Thanks for the report. There is indeed an issue in how the CPU time is
accounted on an idle system. The below diff is a possible fix.

In roundrobin() force a resched and therefor mi_switch() when
SPCF_SHOULDYIELD is set. On an idle CPU mi_switch() will just do all
accounting bits but skip the expensive cpu_switchto() since the proc
remains the same.

-- 
:wq Claudio

Index: kern/sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.84
diff -u -p -r1.84 sched_bsd.c
--- kern/sched_bsd.c29 Aug 2023 16:19:34 -  1.84
+++ kern/sched_bsd.c29 Aug 2023 16:20:03 -
@@ -106,7 +106,7 @@ roundrobin(struct clockintr *cl, void *c
}
}
 
-   if (spc->spc_nrun)
+   if (spc->spc_nrun || spc->spc_schedflags & SPCF_SHOULDYIELD)
need_resched(ci);
 }
 

Re: pf nat-to doesn't match a crafted packet

[Peter J. Philipp]

On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote:
> Hello,
> 
> On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote:
> > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> > > How are you injecting the crafted packet into the stack?
> > 
> > Via BPF.  It is a spoofing program that I made 23 years ago.  While that's
> > not really a great achievement it found at least 5 or so panic conditions
> > on OpenBSD throughout its existance, for which I'm sure everyone is grateful
> > for.  I am willing to share it (I have shared it in the past), but now only
> > for @openbsd.org addresses, I keep hacking on it time and time again,
> > but it only does IPv4 unless it reads the entire frame which I've never 
> > tried
> > I don't think.  Anyhow regarding the panics they pop up whenever I get
> > "creative" with packets, which keeps me away from what I really wanted to
> > achieve.
> > 
> > So in private conversation I had with Alexandr, I noticed that in the 
> > OpenBSD
> > pf firewall there is this statement in the pf.conf manpage (which is a lie).
> > 
> >ICMP responses are not permitted unless they either match an
> >  existing request, or unless no state or keep state (sloppy) is
> >  specified.
> > 
> > 
> 
> the paragraph you quote assumes a context of stateful packet filtering.
> however the truth is that if ICMP response packet does not match existing
> state (existing request), then the ICMP packet fate depends on rules which
> is covered in second paragraph in 'PACKET FILTERING' section:
> 
>  Each time a packet processed by the packet filter comes in on or goes out
>  through an interface, the filter rules are evaluated in sequential order,
>  from first to last.  For block and pass, the last matching rule decides
>  what action is taken; if no rule matches the packet, the default action
>  is to pass the packet without creating a state.  For match, rules are
>  evaluated every time they match; the pass/block state of a packet remains
>  unchanged.
> 
> 
> regards
> sashan

Hi,

I would like to upgrade this firewall to -current and repeat this test.  Is
that OK or do you need it for any backtracking?  It currently is 7.3 arm64.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: pf nat-to doesn't match a crafted packet

[Peter J. Philipp]

On Tue, Aug 29, 2023 at 12:35:47PM +0200, Claudio Jeker wrote:
> On Tue, Aug 29, 2023 at 12:16:23PM +0200, Peter J. Philipp wrote:
> > On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote:
> > > Hello,
> > > 
> > > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote:
> > > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> > > > > How are you injecting the crafted packet into the stack?
> > > > 
> > > > Via BPF.  It is a spoofing program that I made 23 years ago.  While 
> > > > that's
> 
> If you inject packets via BPF they skip the network stack and therfor do
> not pass pf. So pf(4) has no clue about that packet.
> This is why for dhcp no extra rules are required.
> 
> -- 
> :wq Claudio

Hi Claudio,

I know this, but this injection was on a host behind the firewall/gateway 1
hop.  The injection is on another stack.  And I did say this and the ttl's
on the tcpdump do indicated 64 ttl on the host where I'm injecting and 63
on the pppoe0 interface.  Sorry if I didn't communicate it better.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: pf nat-to doesn't match a crafted packet

[Claudio Jeker]

On Tue, Aug 29, 2023 at 12:16:23PM +0200, Peter J. Philipp wrote:
> On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote:
> > Hello,
> > 
> > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote:
> > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> > > > How are you injecting the crafted packet into the stack?
> > > 
> > > Via BPF.  It is a spoofing program that I made 23 years ago.  While that's

If you inject packets via BPF they skip the network stack and therfor do
not pass pf. So pf(4) has no clue about that packet.
This is why for dhcp no extra rules are required.

-- 
:wq Claudio

Re: pf nat-to doesn't match a crafted packet

[Peter J. Philipp]

On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote:
> Hello,
> 
> On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote:
> > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> > > How are you injecting the crafted packet into the stack?
> > 
> > Via BPF.  It is a spoofing program that I made 23 years ago.  While that's
> > not really a great achievement it found at least 5 or so panic conditions
> > on OpenBSD throughout its existance, for which I'm sure everyone is grateful
> > for.  I am willing to share it (I have shared it in the past), but now only
> > for @openbsd.org addresses, I keep hacking on it time and time again,
> > but it only does IPv4 unless it reads the entire frame which I've never 
> > tried
> > I don't think.  Anyhow regarding the panics they pop up whenever I get
> > "creative" with packets, which keeps me away from what I really wanted to
> > achieve.
> > 
> > So in private conversation I had with Alexandr, I noticed that in the 
> > OpenBSD
> > pf firewall there is this statement in the pf.conf manpage (which is a lie).
> > 
> >ICMP responses are not permitted unless they either match an
> >  existing request, or unless no state or keep state (sloppy) is
> >  specified.
> > 
> > 
> 
> the paragraph you quote assumes a context of stateful packet filtering.
> however the truth is that if ICMP response packet does not match existing
> state (existing request), then the ICMP packet fate depends on rules which
> is covered in second paragraph in 'PACKET FILTERING' section:
> 
>  Each time a packet processed by the packet filter comes in on or goes out
>  through an interface, the filter rules are evaluated in sequential order,
>  from first to last.  For block and pass, the last matching rule decides
>  what action is taken; if no rule matches the packet, the default action
>  is to pass the packet without creating a state.  For match, rules are
>  evaluated every time they match; the pass/block state of a packet remains
>  unchanged.
> 
> 
> regards
> sashan

Hi,

So I shared my pf.conf with you and sthen so that we're not guessing anymore,
I should have done this earlier.  There is a pass from  to any in
anchor "pppoe0 inet" but before that is a NAT match rule in the NAT anchor.

So my question is the following.  Why does this match not work?  And why is
there no state made for this packet though I specified keep state in the pass
in last paragraph.  This packet is an odd one to me for sure.

Am I being difficult here?  Sorry if you think I am.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: pf nat-to doesn't match a crafted packet

[Alexandr Nedvedicky]

Hello,

On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote:
> On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> > How are you injecting the crafted packet into the stack?
> 
> Via BPF.  It is a spoofing program that I made 23 years ago.  While that's
> not really a great achievement it found at least 5 or so panic conditions
> on OpenBSD throughout its existance, for which I'm sure everyone is grateful
> for.  I am willing to share it (I have shared it in the past), but now only
> for @openbsd.org addresses, I keep hacking on it time and time again,
> but it only does IPv4 unless it reads the entire frame which I've never tried
> I don't think.  Anyhow regarding the panics they pop up whenever I get
> "creative" with packets, which keeps me away from what I really wanted to
> achieve.
> 
> So in private conversation I had with Alexandr, I noticed that in the OpenBSD
> pf firewall there is this statement in the pf.conf manpage (which is a lie).
> 
>ICMP responses are not permitted unless they either match an
>  existing request, or unless no state or keep state (sloppy) is
>  specified.
> 
> 

the paragraph you quote assumes a context of stateful packet filtering.
however the truth is that if ICMP response packet does not match existing
state (existing request), then the ICMP packet fate depends on rules which
is covered in second paragraph in 'PACKET FILTERING' section:

 Each time a packet processed by the packet filter comes in on or goes out
 through an interface, the filter rules are evaluated in sequential order,
 from first to last.  For block and pass, the last matching rule decides
 what action is taken; if no rule matches the packet, the default action
 is to pass the packet without creating a state.  For match, rules are
 evaluated every time they match; the pass/block state of a packet remains
 unchanged.


regards
sashan

Re: find(1) with -delete ignores -maxdepth

[Andreas Kusalananda Kähäri]

On Tue, Aug 29, 2023 at 09:41:34AM +0200, Marcus MERIGHI wrote:
> Hello,
> 
> thanks for taking a look! My reproducer is at the end.
> 
> What I missed to state: this is on amd64,
> OpenBSD 7.3-current (GENERIC.MP) #1356: Mon Aug 28 09:35:30 MDT 2023
> 
> kern...@gmail.com (George Koehler), 2023.08.28 (Mon) 22:01 (CEST):
> > On Mon, 28 Aug 2023 12:42:39 +0200
> > Marcus MERIGHI  wrote:
> > 
> > > My complete crontab(5) entry reads:
> > > 
> > > /usr/bin/find ~/ -maxdepth 1 -fstype local -name "*.core" -delete
> > > 
> > > Now I get error messages saying "Access Denied" for directories that
> > > find(1) should not access due to "-maxdepth 1". 
> > 
> > I can't produce such errors.  I observe that -maxdepth 1 and -delete
> > work well together.  There's no bug unless someone can provide more
> > specific instructions to produce the error.
> 
> $ cd /tmp
> $ mkdir -p foo/bar/baz
> $ chmod a= foo/bar/baz
> $ cd foo
> $ find . -maxdepth 1 -fstype local -name "*.core"
> $ find . -maxdepth 1 -fstype local -name "*.core" -delete
> find: ./bar/baz: Permission denied


The "-fstype local" is not needed to reproduce the issue, and the
"-delete" may be replaced by anything that causes a depth-first
traversal of the directory tree, such as the "-d" option or the "-depth"
primary.

The way that OpenBSD implements the non-standard "-maxdepth" primary is
slightly different to how e.g. GNU find implements it, in how it plays
with a depth-first operation.  In OpenBSD find, a depth-first traversal
is not limited by "-maxdepth" in the same way as in GNU find, it's just
that the primary will not match anything beneath the specified depth.
This is why the error message is generated in the example above (and not
when using GNU find); find tries to find a leaf directory first, and
*then* applies the primaries to the found pathnames.

Or so I presume.

It's IMHO not an actual bug (seeing as the primary in question is not
standard to start with), just unexpected behaviour (that may be worth
changing).

> 
> Marcus

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.

Re: pf nat-to doesn't match a crafted packet

[Peter J. Philipp]

On Mon, Aug 28, 2023 at 07:13:29PM +0100, Stuart Henderson wrote:
> On 2023/08/28 18:30, Peter J. Philipp wrote:
> > Here is my icmp rulesets:
> > 
> > root@stern# grep icmp /etc/pf.conf
> 
> a partial pf.conf fragment is hardly ever enough to debug a ruleset
> problem. if a packet doesn't match any rule then it hits the implicit
> "pass flags any no state" rule 0.

Sorry Stuart, I missed your message somehow.  I pasted my rules to Alexandr
privately.  It is full of anchors and if he wants contents of the anchors
I asked him to ask for more.

Going by dhartmei's "don't share rules in public" I'm not going to do that
but if you would like a list ask privately.

Best Regards,
-peter

-- 
Over thirty years experience on Unix-like Operating Systems starting with QNX.

Re: pf nat-to doesn't match a crafted packet

[Peter J. Philipp]

On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> How are you injecting the crafted packet into the stack?

Via BPF.  It is a spoofing program that I made 23 years ago.  While that's
not really a great achievement it found at least 5 or so panic conditions
on OpenBSD throughout its existance, for which I'm sure everyone is grateful
for.  I am willing to share it (I have shared it in the past), but now only
for @openbsd.org addresses, I keep hacking on it time and time again,
but it only does IPv4 unless it reads the entire frame which I've never tried
I don't think.  Anyhow regarding the panics they pop up whenever I get
"creative" with packets, which keeps me away from what I really wanted to
achieve.

So in private conversation I had with Alexandr, I noticed that in the OpenBSD
pf firewall there is this statement in the pf.conf manpage (which is a lie).

   ICMP responses are not permitted unless they either match an
 existing request, or unless no state or keep state (sloppy) is
 specified.


Because in net/pf.c this line appears:

   5584 if (ret >= 0)
   5585 return (ret);

And well.. what is returned is negative which falls through to this:

   6357
   6358 return (PF_PASS);


15 year old bug and 10 year old bugs respectively.

Best Regards,
-peter

> On Tue, 29 Aug 2023, 01:14 ,  wrote:
> 
> > >Synopsis:  pf nat-to doesn't match a crafted packet
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25
> > MDT 2023
> >  dera...@arm64.openbsd.org:
> > /usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > I was testing a seemingly valid Internet packet going out my
> > gateway
> > but the pf firewall doesn't match nat-to to this one for some reason.  I'm
> > possibly overlooking something but every other packet exiting my gateway is
> > nat'ed.  What causes this?  How can this be exploited?
> >
> > >How-To-Repeat:
> > Here is the tcpdump from the host 1 hop behind the NAT router:
> >
> > 16:59:08.438082 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreachable [icmp cksum ok] for 11.69.44.241.52699 > 7.198.187.211.55672:
> > udp 51351 [tos 0x9c] (ttl 147, id 17124, len 51419, optlen=40 NOP RR{39}=
> > RR{#106.155.117.54 233.26.79.111 129.127.249.242 60.117.146.16
> > 179.39.29.224 213.65.49.78 0.16.45.109 252.168.188.0 123.108.138.224}) (ttl
> > 64, id 65443, len 96)
> >   : 4500 0060 ffa3  4001 ad81 c0a8 b10d  E..`@...
> >   0010: 310c 2ab6 0301 55aa   4f9c c8db  1.*...U.O...
> >   0020: 42e4  9311 c756 0b45 2cf1 07c6 bbd3  B..V.E,.
> >   0030: 0107 2704 6a9b 7536 e91a 4f6f 817f f9f2  ..'.j.u6..Oo
> >   0040: 3c75 9210 b327 1de0 d541 314e 0010 2d6d   >   0050: fca8 bc00 7b6c 8ae0 cddb d978    {l.x
> >
> > and here is the tcpdump on the pppoe interface:
> >
> > 16:59:08.440403 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreacha
> > ble [icmp cksum ok] (ttl 63, id 65443, len 96)
> >
> > Here is the relevant anchor rules I have:
> >
> >match out on $ext_if inet from  to any nat-to ($ext_if)
> >
> > and:
> >
> > table  const { 10/8, 172.16/12, 192.168/16 }
> >
> > Why did pf not translate this?  ... that's kinda kinky.
> >
> > >Fix:
> > Not known.
> >
> >
> > dmesg:
> > OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > real mem  = 8432840704 (8042MB)
> > avail mem = 8139239424 (7762MB)
> > random: good seed from bootblocks
> > mainbus0 at root: ACPI
> > psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
> > cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
> > cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu0: 1024KB 64b/line 16-way L2 cache
> > cpu0: CRC32,ASID16
> > cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
> > cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu1: 1024KB 64b/line 16-way L2 cache
> > cpu1: CRC32,ASID16
> > cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
> > cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu2: 1024KB 64b/line 16-way L2 cache
> > cpu2: CRC32,ASID16
> > cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
> > cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu3: 1024KB 64b/line 16-way L2 cache
> > cpu3: CRC32,ASID16
> > efi0 at mainbus0: UEFI 2.7
> > efi0: https://github.com/pftf/RPi4 rev 0x1
> > smbios0 at efi0: SMBIOS 3.3.0
> > smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware
> > v1.21" date 11/13/2020
> > smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
> > apm0 at mainbus0
> > ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 

Re: find(1) with -delete ignores -maxdepth

[Marcus MERIGHI]

Hello,

thanks for taking a look! My reproducer is at the end.

What I missed to state: this is on amd64,
OpenBSD 7.3-current (GENERIC.MP) #1356: Mon Aug 28 09:35:30 MDT 2023

kern...@gmail.com (George Koehler), 2023.08.28 (Mon) 22:01 (CEST):
> On Mon, 28 Aug 2023 12:42:39 +0200
> Marcus MERIGHI  wrote:
> 
> > My complete crontab(5) entry reads:
> > 
> > /usr/bin/find ~/ -maxdepth 1 -fstype local -name "*.core" -delete
> > 
> > Now I get error messages saying "Access Denied" for directories that
> > find(1) should not access due to "-maxdepth 1". 
> 
> I can't produce such errors.  I observe that -maxdepth 1 and -delete
> work well together.  There's no bug unless someone can provide more
> specific instructions to produce the error.

$ cd /tmp
$ mkdir -p foo/bar/baz
$ chmod a= foo/bar/baz
$ cd foo
$ find . -maxdepth 1 -fstype local -name "*.core"
$ find . -maxdepth 1 -fstype local -name "*.core" -delete
find: ./bar/baz: Permission denied

Marcus