Re: Upgrading from already downloaded sets is broken?

[Lampshade]

I also hit that problem when upgrading
current. A few chmod ugo+x on directories
and chmod ugo+r on files and dirs later
everything worked correctly.

But I have known from this thread ahead
that this is about dropped privileges.

Re: Upgrading from already downloaded sets is broken?

[Laurence Tratt]

On Tue, Oct 04, 2016 at 04:58:36PM -0600, Theo de Raadt wrote:

Hello Theo,

> anyways, rpe and I have discussed and figured out a solution that will
> allow the old method to work.  It is just unfortunate it takes so much
> effort to maintain old strange methods for everyone.

Thanks to Robert and yourself for taking the trouble on this one -- I for one
really appreciate it.


Laurie
-- 
Personal http://tratt.net/laurie/
Software Development Teamhttp://soft-dev.org/
   https://github.com/ltratt  http://twitter.com/laurencetratt

Re: Upgrading from already downloaded sets is broken?

[Theo de Raadt]

> Tue, 4 Oct 2016 21:26:55 +0100 Laurence Tratt 
> > Yes, like most others it seems, I can go years without checking INSTALL
> > (after 17 years of using OpenBSD, it's easy to think that I know its 
> > content).
> 
> And just when you needed you either missed it or preferred to whine.
> I personally would preferred you did not have that much preferences.
> 
> > I did however check the "following current" page on the website. I check 
> > that
> > every so often (and whenever I hit a problem). [I often check the CVS list
> > too, although in this case I looked for completely the wrong thing.]
> 
> It is recommendable you kept track of OS changes before you got into
> changes your end to stay on top of any discrepancy, and when you do,
> you fix your ways to accommodate to the evolving software to be able
> to cooperate w/ improvements, instead of counter productively whine.
> For the greater good of the large group than your own, do cooperate.


whatever

anyways, rpe and I have discussed and figured out a solution that
will allow the old method to work.  It is just unfortunate it takes
so much effort to maintain old strange methods for everyone.

Re: Upgrading from already downloaded sets is broken?

[Laurence Tratt]

On Tue, Oct 04, 2016 at 01:13:42PM -0600, Theo de Raadt wrote:

Hello Theo,

>> However, if the new behaviour is preferred, it might be worth documenting
>> it somewhere.
> If this was mentioned in the INSTALL notes would you have seen it before
> running into it?  Go ahead, look at the document.  Where in the document
> should it be.  Please make sure you point out a spot that you *WOULD HAVE
> READ* before running into this.
>
> Then what, shall we document 50 things about the installer?  Noone will
> read it.  We already know this file is rarely downloaded.

Yes, like most others it seems, I can go years without checking INSTALL
(after 17 years of using OpenBSD, it's easy to think that I know its content).

I did however check the "following current" page on the website. I check that
every so often (and whenever I hit a problem). [I often check the CVS list
too, although in this case I looked for completely the wrong thing.]


Laurie
-- 
Personal http://tratt.net/laurie/
Software Development Teamhttp://soft-dev.org/
   https://github.com/ltratt  http://twitter.com/laurencetratt

Re: Upgrading from already downloaded sets is broken?

[Theo de Raadt]

> OK, so now I understand the message (/home/ltratt/tmp is drwx--). That
> said, the behaviour is maybe a little surprising, as I expect(ed) to be doing
> everything in the upgrader as root.

Please go read rpe's mail a second time.  This is ensuring that most
of the installer -- based upon input -- cannot corrupt your system.
It is a security move.

> My personal (biased :)) preference would be to maintain the original
> behaviour, as I suspect I won't be the only one caught out by this.

Ah, the rich behaviour of "it worked before, it should keep working
exactly the same".  Please make software better, but don't break something
noone ever knew anyone depended on.  And do it for free.  Please.

> However, if the new behaviour is preferred, it might be worth
> documenting it somewhere.

If this was mentioned in the INSTALL notes would you have seen
it before running into it?  Go ahead, look at the document.  Where in
the document should it be.  Please make sure you point out a spot that
you *WOULD HAVE READ* before running into this.

Then what, shall we document 50 things about the installer?  Noone will
read it.  We already know this file is rarely downloaded.

> I must admit that I don't know a sensible place to document it
> without becoming over-fussy though :/ Maybe a low-tech fix is to catch the
> "permission denied" message and substitute it for something like "User
>  can't access ", at least for
> the next release while people are inducted into the new behaviour? That
> message might be a bit fiddly though...

I really doubt the drama of this.

Re: Upgrading from already downloaded sets is broken?

[Laurence Tratt]

On Tue, Oct 04, 2016 at 06:23:24PM +, Robert Peichaer wrote:

Hello Robert,

Thanks for your quick reply!

>> The last couple of snapshots seem to have changed the behaviour of
>> upgrading. If when asked "Location of sets?" I select "disk", and type in
>> an appropriate mounted location, the correct sets are presented to me.
>> However, when I select "done" to install the sets, I get the following:
> The installer script now uses the unpriv() wrapper to fetch the set files
> as unprivileged user (see cvs log below).
> Before, the root user was able to fetch the files no matter what the
> ownership/permissions were.

OK, so now I understand the message (/home/ltratt/tmp is drwx--). That
said, the behaviour is maybe a little surprising, as I expect(ed) to be doing
everything in the upgrader as root. It didn't even occur to me that an
unprivileged user might be the culprit.

My personal (biased :)) preference would be to maintain the original
behaviour, as I suspect I won't be the only one caught out by this. However,
if the new behaviour is preferred, it might be worth documenting it
somewhere. I must admit that I don't know a sensible place to document it
without becoming over-fussy though :/ Maybe a low-tech fix is to catch the
"permission denied" message and substitute it for something like "User
 can't access ", at least for
the next release while people are inducted into the new behaviour? That
message might be a bit fiddly though...


Laurie

Re: Upgrading from already downloaded sets is broken?

[Robert Peichaer]

On Tue, Oct 04, 2016 at 07:06:30PM +0100, Laurence Tratt wrote:
> >Synopsis:Upgrading from sets on a mounted disk no longer works
> >Environment:
>   System  : OpenBSD 6.0
>   Details : OpenBSD 6.0-current (GENERIC.MP) #2518: Sun Oct  2 
> 21:41:07 MDT 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> The last couple of snapshots seem to have changed the behaviour of upgrading. 
> If
> when asked "Location of sets?" I select "disk", and type in an appropriate
> mounted location, the correct sets are presented to me. However, when I select
> "done" to install the sets, I get the following:
> 
>   ftp: Can't open file mnt/home/ltratt/tmp/bsd/SHA256.sig: Permission 
> denied
>   Cannot fetch SHA256.sig. Continue without verification? [no]
> 
> The file(s) exist, and if I manually use ftp from the shell (with a file:///
> URL), there is no permission problem at all. I assume, but don't know, that
> the install script is calling ftp incorrectly?
> >How-To-Repeat:
> Happens on two amd64 machines I have access to.

The installer script now uses the unpriv() wrapper to fetch the set
files as unprivileged user (see cvs log below).
Before, the root user was able to fetch the files no matter what the
ownership/permissions were.

revision 1.908
date: 2016/09/03 11:29:17;  author: rpe;  state: Exp;  lines: +46 -1;
Add a do_as() function that executes commands as unprivileged user
and ensures that no processes of this user remain active afterwards.
Optionally, it creates a file, that is owned by the user only for
this command execution. Afterwards it's chown'd by root.

Add wrapper functions for do_as(). unpriv() uses the _sndio user
and unpriv2() uses the _file user to execute commands.

OK halex, tb, deraadt

Upgrading from already downloaded sets is broken?

[Laurence Tratt]

>Synopsis:  Upgrading from sets on a mounted disk no longer works
>Environment:
System  : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #2518: Sun Oct  2 
21:41:07 MDT 2016
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
The last couple of snapshots seem to have changed the behaviour of upgrading. If
when asked "Location of sets?" I select "disk", and type in an appropriate
mounted location, the correct sets are presented to me. However, when I select
"done" to install the sets, I get the following:

  ftp: Can't open file mnt/home/ltratt/tmp/bsd/SHA256.sig: Permission denied
  Cannot fetch SHA256.sig. Continue without verification? [no]

The file(s) exist, and if I manually use ftp from the shell (with a file:///
URL), there is no permission problem at all. I assume, but don't know, that
the install script is calling ftp incorrectly?
>How-To-Repeat:
Happens on two amd64 machines I have access to.
>Fix:
dmesg:
OpenBSD 6.0-current (GENERIC.MP) #2518: Sun Oct  2 21:41:07 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17060859904 (16270MB)
avail mem = 16539250688 (15773MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xc51d6000 (90 entries)
bios0: vendor American Megatrends Inc. version "1805" date 06/20/2016
bios0: ASUSTeK COMPUTER INC. Z170M-PLUS
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT SSDT 
DBGP DBG2 SSDT SSDT UEFI SSDT BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
UAR1(S4) PS2K(S3) PS2M(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) 
RP11(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4121.54 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4120.07 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4120.07 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4120.07 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 4 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus 3 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)