Hi,
Here are the pcidumps from both the working mfii0 and mfii0 after warm reboot:
https://www.klos.com/~john/pcidump_raid.txt
https://www.klos.com/~john/pcidump_noraid.txt
This is what's different:
3c3
< 0x00: 0x005b1000 0x0010 0x01040003 0x
---
0x00: 0x005b1000
> a likely source of security issues.
Why, exactly? I hope you need search permission to the original file
(you certainly need search and write permission to the destination directory),
so what can you do after the link you couldn't have done before?
What about rename instead of link, should
[trimming tech-userlevel and tech-kern from cc list to avoid
cross-posting the entire thread]
> Date: Thu, 7 Sep 2023 11:53:56 + (UTC)
> From: RVP
>
> On Thu, 7 Sep 2023, Taylor R Campbell wrote:
>
> > I think we should have these knobs on by default, but of course in
> > principle that
On Thu, 7 Sep 2023, Taylor R Campbell wrote:
I think we should have these knobs on by default, but of course in
principle that might break existing configurations. So maybe we could
put it in the default /etc/sysctl.conf -- that way you only get it on
upgrade if you merge updates to /etc.
I
Today I learned that you can create hard links to a file you don't own
and can't write to or even read from:
$ su -l root -c 'touch /tmp/foo && chmod 600 /tmp/foo'
$ ln /tmp/foo /tmp/bar
This strikes me as bonkers and a likely source of security issues.
POSIX says:
> The implementation may
Hello
RaidFrame lacks the ability to remove failed components and hot spares,
which require a reboot to replace a dead disk. I have been working with
Greg Oster to address that. I now have code that passes basic tests, it
needs review. Please find it attached.
What's new?
- Removing an unused
