Re: Is loss of read-only /usr permanent?

[Stuart Henderson]

On 2016/05/16 14:22, Craig Skinner wrote:
> On 2016-05-14 Sat 12:25 PM |, RD Thrush wrote:
> > 
> > Thanks, Craig.  That is much better than what I proposed
> > 
> 
> Another solution occured to me Bob;-
> 
> ro /usr
> rw /usr/lib (an additional mount point)
> 
> If power was lost during boot, most of /usr would be unaffected.

If /usr/lib is toast, /usr isn't going to do you much good.

Re: Is loss of read-only /usr permanent?

[Craig Skinner]

On 2016-05-14 Sat 12:25 PM |, RD Thrush wrote:
> 
> Thanks, Craig.  That is much better than what I proposed
> 

Another solution occured to me Bob;-

ro /usr
rw /usr/lib (an additional mount point)

If power was lost during boot, most of /usr would be unaffected.

The mods I mailed earlier could also be adapted for a ro /usr/lib too.

Cheers!
-- 
Q:  What is the last thing a Kansas stripper takes off?
A:  Her bowling shoes.

Re: Is loss of read-only /usr permanent?

[lists]

Sat, 14 May 2016 19:47:59 +0100 Kevin Chadwick 
> > Finally, the read only file systems on a writable medium susceptible
> > to all sorts of failure modes is a silly silly useless trick.  This
> > does not provide any real technical benefit but your own discomfort.
> 
> Pipe it down a bit will you. I use ro root, /dev in tmpfs and /usr ro
> as well as any partition where writes do not happen at any time. It is
> called defence in depth.

It is called self induced inconvenience by deviation from functional
state of the file system.  You're a hazard to your data set, Kevin.

> Consider a potential bug in tar when run as
> root, damaged /usr or / is easily fixed with OpenBSD (one of it's ace
> cards) but I have been saved time by ro root before, though I forget the
> details and probably just a testing system. When considering doas,
> etc., I believe a ro mount to be far simpler than DACs even if they are
> well tested. It is also quite reassuring to see clean clean clean clean
> after a power failure. Of course a hard drive head could have crashed
> onto that area, but very unlikely and I'm not sure fsck would catch
> that anyway.

You forgot the ha-ha bit.  Now seriously go consult with a specialist.

> UPS do fail too btw. I had to rip some cheap APC ones out because
> they caused more downtime than they saved!

Did you just copy paste this line from somewhere?  You can't handle a
battery replacement, and you're advising read only file system mounts.

> > Except just this time now, when your self managing became a bug report,
> > which is not a bug, and you insisted on your way of having it reported.
> > 
> > Now admit it, you support yourself when you make incompatible changes.  
> 
> Which is fair enough but has already been said.

And you felt like trolling a bit nonsense for the laughs on you.  We're
not laughing, it looks a sad place where colleagues are people like you.

Re: Is loss of read-only /usr permanent?

[lists]

Sat, 14 May 2016 12:25:47 -0400 RD Thrush 
> On 05/14/16 04:34, Craig Skinner wrote:
> > Hi RD/all,
> > 
> > On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:  
> >>
> >> # cp -p /etc/fstab /etc/fstab.orig
> >> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> >> # shutdown -f now
> >> Shutdown NOW!
> >> shutdown: [pid 82541]  
> > 
> > Something like this in /etc/rc might help here:
> > 
> > rebuildlibs() {
> > mount -d /usr | fgrep -wq ro && _ro_usr='true'
> > [[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr
> > 
> > ...
> > ..
> > [[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
> > }
> > 
> > 
> > Let us know what works for you.  
> 
> Thanks, Craig.  That is much better than what I proposed [1].  I'll update my
> autoinstall accordingly.
> 
> [1]

Just don't file bug reports for the installer later, when something
moves and your incompatible changes resurface again to bite on your.

Re: Is loss of read-only /usr permanent?

[Kevin Chadwick]

> Finally, the read only file systems on a writable medium susceptible
> to all sorts of failure modes is a silly silly useless trick.  This
> does not provide any real technical benefit but your own discomfort.
> 

Pipe it down a bit will you. I use ro root, /dev in tmpfs and /usr ro
as well as any partition where writes do not happen at any time. It is
called defence in depth. Consider a potential bug in tar when run as
root, damaged /usr or / is easily fixed with OpenBSD (one of it's ace
cards) but I have been saved time by ro root before, though I forget the
details and probably just a testing system. When considering doas,
etc., I believe a ro mount to be far simpler than DACs even if they are
well tested. It is also quite reassuring to see clean clean clean clean
after a power failure. Of course a hard drive head could have crashed
onto that area, but very unlikely and I'm not sure fsck would catch
that anyway.

UPS do fail too btw. I had to rip some cheap APC ones out because
they caused more downtime than they saved!

> 
> Except just this time now, when your self managing became a bug report,
> which is not a bug, and you insisted on your way of having it reported.
> 
> Now admit it, you support yourself when you make incompatible changes.

Which is fair enough but has already been said.

-- 

KISSIS - Keep It Simple So It's Securable

Re: Is loss of read-only /usr permanent?

[lists]

Sat, 14 May 2016 12:24:50 -0400 RD Thrush 
> On 05/13/16 23:34, Theo de Raadt wrote:
> >> The report is fairly easy to reproduce.  Make the /usr filesystem
> >> read-only in /etc/fstab, go to single user mode and exit back to
> >> multi-user.  I've appended a transcript.  
> > 
> > This does not matter.  It is your configuration.  It is not the default.
> > 
> > Can you make /usr readonly on 90% of other operating systems, without
> > downsides?  Then switch.  The reality is that you can't, since it is
> > your own brave configuration choice.  You own it.
> >   
> >> It's unfortunate that mounting /usr read-only is now a mis-configuration.  
> > 
> > It was never a valid configuration.  Next up, you will ask for readonly
> > /etc.  Or readonly /var.  Or readonly something.  Or operation without
> > half the files that are in /etc.  Who knows.
> > 
> > It is your change --> you own it.  
> 
> I have nothing but praise for the related security improvement as well as 
> countless others that influenced my choice of OpenBSD since 2.6. I have 
> upgraded 100s of times with /usr{,/X11R*,/local} as ro in /etc/fstab.  I made 
> the 'bugs' report including a diff [1] two weeks ago when I noticed the 
> conflict after a -current upgrade.

Look, you don't have to make it public, that you make changes your end.

You don't have to make requests that everyone gets a change because of
how you choose to use the system.  And you don't have to insist you're
doing what's appropriate for others, because you don't choose correct.

Finally, the read only file systems on a writable medium susceptible
to all sorts of failure modes is a silly silly useless trick.  This
does not provide any real technical benefit but your own discomfort.

> After no response, I asked again and unintentionally triggered angry 
> responses, although 2 good suggestions emerged.

Yes, one was don't deviate from the default in this respect, and the
other was, obviously, you're on your own with that change, you own it.

> Edgar Pettijohn [2] suggested adding the mount -ur ... commands to 
> /etc/rc.local which works but may warrant a note when [3] is created.
> 
> Craig Skinner [4] greatly improved my diff. 
> 
> I've been managing the read-only /usr partitions since the change w/ a custom 
> autoinstall.
> 
> [1]
> [2]
> [3]
> [4]

Except just this time now, when your self managing became a bug report,
which is not a bug, and you insisted on your way of having it reported.

Now admit it, you support yourself when you make incompatible changes.

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

> Thanks, that would work fine.  It may be useful as a note in the upgrade guide
> for 6.0 for those (apparently few of us) who have a read-only /usr.

The documentation describes the system as it is shipped.

It does not spend hundreds of pages satisfying tweakers.
 

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 19:37, Edgar Pettijohn wrote:
>> On May 13, 2016, at 4:16 PM, RD Thrush  wrote:
>>
>> On 05/13/16 11:07, Theo de Raadt wrote:
 Since the anti-ROP mechanism in libc [2] was added in late April, -current 
 with read-only /usr produces something like the following message:
 re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
 system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
 I thought I was following best practice by mounting /usr,
 /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
 patch to fix my problem [2] but have had no response.
>>>
>>> That is not best practice.  If it was, we would be heading towards
>>> making it the default.
>>>
>>> And why is not best practice? Because it stands directly against the
>>> primary purpose of OpenBSD: A development platform, where people
>>> constantly rebuild their binaries, iterating and fixing bugs.
>>>
>>> What you are describing here is really just "you make a local change,
>>> you own it".
>>
>> [ ... snip ... ]
> 
> Why not just put the appropriate mount command in /etc/rc.local?

Thanks, that would work fine.  It may be useful as a note in the upgrade guide
for 6.0 for those (apparently few of us) who have a read-only /usr.

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 23:34, Theo de Raadt wrote:
>> The report is fairly easy to reproduce.  Make the /usr filesystem
>> read-only in /etc/fstab, go to single user mode and exit back to
>> multi-user.  I've appended a transcript.
> 
> This does not matter.  It is your configuration.  It is not the default.
> 
> Can you make /usr readonly on 90% of other operating systems, without
> downsides?  Then switch.  The reality is that you can't, since it is
> your own brave configuration choice.  You own it.
> 
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 
> It was never a valid configuration.  Next up, you will ask for readonly
> /etc.  Or readonly /var.  Or readonly something.  Or operation without
> half the files that are in /etc.  Who knows.
> 
> It is your change --> you own it.

I have nothing but praise for the related security improvement as well as 
countless others that influenced my choice of OpenBSD since 2.6. I have 
upgraded 100s of times with /usr{,/X11R*,/local} as ro in /etc/fstab.  I made 
the 'bugs' report including a diff [1] two weeks ago when I noticed the 
conflict after a -current upgrade.

After no response, I asked again and unintentionally triggered angry responses, 
although 2 good suggestions emerged.

Edgar Pettijohn [2] suggested adding the mount -ur ... commands to 
/etc/rc.local which works but may warrant a note when [3] is created.

Craig Skinner [4] greatly improved my diff. 

I've been managing the read-only /usr partitions since the change w/ a custom 
autoinstall.

[1]
[2]
[3]
[4]

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 19:40, Chris Cappuccio wrote:
> RD Thrush [openbsd-t...@thrush.com] wrote:
>> On 05/13/16 11:07, Theo de Raadt wrote:
 Since the anti-ROP mechanism in libc [2] was added in late April, -current 
 with read-only /usr produces something like the following message:
 re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
 system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
> 
> Robert, what do you suggest?
> 
> 1. Say sorry, no mitigation because we want to support all possible
> configurations
> 
> 2. Say OK, and provide a work-around in /etc/rc that might (or might not)
> work with your situation, and makes the overall situation more complicated
> for everyone
> 
> 3. Say sorry, the mitigation technique will not be changed. You are on your
> own.
> 
> I think it comes down to this. If you want read-only /etc, you'll have to
> modify /etc/rc, if you still want the mitigation.

Thanks, Chris.  I provided a diff in my original bugs report.  Craig Skinner
enhanced it and I'll update my autoinstall accordingly.

I didn't mention read-only /etc.  Not sure where that came from.

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/14/16 04:34, Craig Skinner wrote:
> Hi RD/all,
> 
> On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:
>>
>> # cp -p /etc/fstab /etc/fstab.orig
>> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
>> # shutdown -f now
>> Shutdown NOW!
>> shutdown: [pid 82541]
> 
> Something like this in /etc/rc might help here:
> 
> rebuildlibs() {
>   mount -d /usr | fgrep -wq ro && _ro_usr='true'
>   [[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr
>   
>   ...
>   ..
>   [[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
> }
> 
> 
> Let us know what works for you.

Thanks, Craig.  That is much better than what I proposed [1].  I'll update my
autoinstall accordingly.

[1]

Re: Is loss of read-only /usr permanent?

[lists]

Fri, 13 May 2016 17:16:19 -0400 RD Thrush 
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system  
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.  
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.

Then don't do what you report and it won't happen, it's like putting a
stick in your feet and complaining you nose dive roughly reproducible.

> > That is the result of a mis-configuration on your part.  
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.

Yes, unlucky to be you having to do it and file a report that you did.

> >> I thought I was following best practice by mounting /usr,
> >> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
> >> patch to fix my problem [2] but have had no response.  
> > 
> > That is not best practice.  If it was, we would be heading towards
> > making it the default.
> > 
> > And why is not best practice? Because it stands directly against the
> > primary purpose of OpenBSD: A development platform, where people
> > constantly rebuild their binaries, iterating and fixing bugs.
> > 
> > What you are describing here is really just "you make a local change,
> > you own it".

Re: Is loss of read-only /usr permanent?

[lists]

Fri, 13 May 2016 18:55:58 -0500 Chris Bennett

> I think you are totally missing the point that Theo just made.

You too.

> Marking partitions as read-only is useful, when and only when
> appropriate.

Expand on a wrong idea does not make it right.  Your advice is hurting
naive readers.  This thread is the result of a user error gone public.

> Why, because when the power fails, no data is lost and I'm quickly back
> up with minimal fsck'ing.

Obvious design error: you did not include uninterrupted power supply.
File system check is fast and safe even when power fails.  Still you
have a system reliability omission.  Consider a power unit next time.

> This has saved my ass twice now.

By hurting you in the long run, useless trick.

> Backup your data

After you have reliable power and learn a lot more on system design.

Re: Is loss of read-only /usr permanent?

[Craig Skinner]

Hi RD/all,

On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:
> 
> # cp -p /etc/fstab /etc/fstab.orig
> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> # shutdown -f now
> Shutdown NOW!
> shutdown: [pid 82541]

Something like this in /etc/rc might help here:

rebuildlibs() {
mount -d /usr | fgrep -wq ro && _ro_usr='true'
[[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr

...
..
[[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
}


Let us know what works for you.

Thanks!
-- 
Paranoia doesn't mean the whole world isn't out to get you.

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

> I think you are totally missing the point that Theo just made.
> Marking partitions as read-only is useful, when and only when
> appropriate.
> I have:
> /var/www/var
> /home
> /home/user1
> /home/user2
> /usr/local
> 
> all marked as read-only.
> Why, because when the power fails, no data is lost and I'm quickly back
> up with minimal fsck'ing.
> When user1 or user2 logs in, There is a big message telling them to
> mount their partition rw and right before logging out or shutting down,
> to mark as ro.
> When the lights start to flicker, Ctrl-Alt-Backspace slams you out of X
> and ro alias slams that partition safe much faster than shutdown.
> This has saved my ass twice now.
> 
> Backup your data and re-install that snapshot if you lose /usr, etc.
> Works great for me. Many times.
> You are backing up etc and root, right?

That's good Chris --

You have built a setup you like, and you handle the subtle issues
associated with that choice.

Meaning you wouldn't file a bug report.  It is your choice, and you
make the downsides of that choice work.

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

> The report is fairly easy to reproduce.  Make the /usr filesystem
> read-only in /etc/fstab, go to single user mode and exit back to
> multi-user.  I've appended a transcript.

This does not matter.  It is your configuration.  It is not the default.

Can you make /usr readonly on 90% of other operating systems, without
downsides?  Then switch.  The reality is that you can't, since it is
your own brave configuration choice.  You own it.

> It's unfortunate that mounting /usr read-only is now a mis-configuration.

It was never a valid configuration.  Next up, you will ask for readonly
/etc.  Or readonly /var.  Or readonly something.  Or operation without
half the files that are in /etc.  Who knows.

It is your change --> you own it.

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

>I think it comes down to this. If you want read-only /etc, you'll have to
>modify /etc/rc, if you still want the mitigation.

I want to no readable files in /usr/lib!

PLEASE, the make-programs-run migitation is killing me!

Re: Is loss of read-only /usr permanent?

[Chris Bennett]

I think you are totally missing the point that Theo just made.
Marking partitions as read-only is useful, when and only when
appropriate.
I have:
/var/www/var
/home
/home/user1
/home/user2
/usr/local

all marked as read-only.
Why, because when the power fails, no data is lost and I'm quickly back
up with minimal fsck'ing.
When user1 or user2 logs in, There is a big message telling them to
mount their partition rw and right before logging out or shutting down,
to mark as ro.
When the lights start to flicker, Ctrl-Alt-Backspace slams you out of X
and ro alias slams that partition safe much faster than shutdown.
This has saved my ass twice now.

Backup your data and re-install that snapshot if you lose /usr, etc.
Works great for me. Many times.
You are backing up etc and root, right?
Chris

Re: Is loss of read-only /usr permanent?

[Chris Cappuccio]

RD Thrush [openbsd-t...@thrush.com] wrote:
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
> > That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 

Robert, what do you suggest?

1. Say sorry, no mitigation because we want to support all possible
configurations

2. Say OK, and provide a work-around in /etc/rc that might (or might not)
work with your situation, and makes the overall situation more complicated
for everyone

3. Say sorry, the mitigation technique will not be changed. You are on your
own.

I think it comes down to this. If you want read-only /etc, you'll have to
modify /etc/rc, if you still want the mitigation.

Re: Is loss of read-only /usr permanent?

[Edgar Pettijohn]

Sent from my iPhone

> On May 13, 2016, at 4:16 PM, RD Thrush  wrote:
> 
> On 05/13/16 11:07, Theo de Raadt wrote:
>>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>>> with read-only /usr produces something like the following message:
>>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
>>> system
>> 
>> Look, your statement is false.  I can install a snapshot right now,
>> and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
>> That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 
>>> I thought I was following best practice by mounting /usr,
>>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>>> patch to fix my problem [2] but have had no response.
>> 
>> That is not best practice.  If it was, we would be heading towards
>> making it the default.
>> 
>> And why is not best practice? Because it stands directly against the
>> primary purpose of OpenBSD: A development platform, where people
>> constantly rebuild their binaries, iterating and fixing bugs.
>> 
>> What you are describing here is really just "you make a local change,
>> you own it".
> 
> # cp -p /etc/fstab /etc/fstab.orig
> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> # shutdown -f now
> Shutdown NOW!
> shutdown: [pid 82541]
> #
> ?*** FINAL System shutdown message from r...@obsd32.thrush.com ***?
> System going down IMMEDIATELY
> 
> 
> 
> System shutdown time has arrived
> Enter pathname of shell or RETURN for sh:
> # exit
> Fast boot: skipping disk checks.
> setting tty flags
> pfctl: pf already enabled
> machdep.allowaperture: 2 -> 2
> starting network
> DHCPREQUEST on vio0 to 255.255.255.255
> DHCPACK from 10.1.2.18 (14:da:e9:b5:84:cf)
> bound to 10.1.2.6 -- renewal in 302400 seconds.
> re-ordering libraries:install: /usr/lib/INS@73BiVBOVcW: Read-only file system
> done.
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd smtpd sndiod.
> starting local daemons: cron.
> Fri May 13 16:30:55 EDT 2016
> 
> 
> ##
> OpenBSD 6.0-beta (GENERIC.MP) #1742: Fri May 13 08:52:53 MDT 2016
>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
> cpu0: 
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
> real mem  = 2146844672 (2047MB)
> avail mem = 2093015040 (1996MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd4be, SMBIOS rev. 2.8 @ 
> 0xf0cd0 (9 entries)
> bios0: vendor SeaBIOS version 
> "rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 
> 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC HPET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
> cpu1: 
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> "ACPI0006" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "PNP0F13" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> bios0: ROM list: 0xc/0x9200 0xc9800/0xa00 0xca800/0x2400 0xed000/0x3000!
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
> removable
> cd0(pciide0:1:0): using PIO

Re: Is loss of read-only /usr permanent?

[RD Thrush]

On 05/13/16 11:07, Theo de Raadt wrote:
>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>> with read-only /usr produces something like the following message:
>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system
> 
> Look, your statement is false.  I can install a snapshot right now,
> and I won't see what you report.

The report is fairly easy to reproduce.  Make the /usr filesystem read-only in 
/etc/fstab, go to single user mode and exit back to multi-user.  I've appended 
a transcript.

> That is the result of a mis-configuration on your part.

It's unfortunate that mounting /usr read-only is now a mis-configuration.

>> I thought I was following best practice by mounting /usr,
>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>> patch to fix my problem [2] but have had no response.
> 
> That is not best practice.  If it was, we would be heading towards
> making it the default.
> 
> And why is not best practice? Because it stands directly against the
> primary purpose of OpenBSD: A development platform, where people
> constantly rebuild their binaries, iterating and fixing bugs.
> 
> What you are describing here is really just "you make a local change,
> you own it".

# cp -p /etc/fstab /etc/fstab.orig
# sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
# shutdown -f now
Shutdown NOW!
shutdown: [pid 82541]
#
?*** FINAL System shutdown message from r...@obsd32.thrush.com ***?
System going down IMMEDIATELY



System shutdown time has arrived
Enter pathname of shell or RETURN for sh:
# exit
Fast boot: skipping disk checks.
setting tty flags
pfctl: pf already enabled
machdep.allowaperture: 2 -> 2
starting network
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.1.2.18 (14:da:e9:b5:84:cf)
bound to 10.1.2.6 -- renewal in 302400 seconds.
re-ordering libraries:install: /usr/lib/INS@73BiVBOVcW: Read-only file system
 done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting local daemons: cron.
Fri May 13 16:30:55 EDT 2016


##
OpenBSD 6.0-beta (GENERIC.MP) #1742: Fri May 13 08:52:53 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
real mem  = 2146844672 (2047MB)
avail mem = 2093015040 (1996MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd4be, SMBIOS rev. 2.8 @ 
0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version 
"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu1: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
bios0: ROM list: 0xc/0x9200 0xc9800/0xa00 0xca800/0x2400 0xed000/0x3000!
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emula

Re: Is loss of read-only /usr permanent?

[Theo de Raadt]

> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> with read-only /usr produces something like the following message:
> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system

Look, your statement is false.  I can install a snapshot right now,
and I won't see what you report.

That is the result of a mis-configuration on your part.

> I thought I was following best practice by mounting /usr,
> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
> patch to fix my problem [2] but have had no response.

That is not best practice.  If it was, we would be heading towards
making it the default.

And why is not best practice? Because it stands directly against the
primary purpose of OpenBSD: A development platform, where people
constantly rebuild their binaries, iterating and fixing bugs.

What you are describing here is really just "you make a local change,
you own it".

Is loss of read-only /usr permanent?

[RD Thrush]

Since the anti-ROP mechanism in libc [2] was added in late April, -current with 
read-only /usr produces something like the following message:
re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system

I thought I was following best practice by mounting /usr, /usr/X11R6, and 
/usr/local read-only.  I submitted a bug report and a patch to fix my problem 
[2] but have had no response.

[1]
[2]