Lock order reversal errors during boot

[Will Brokenbourgh]

Greetings,

My first post here so please be gentle.

I am seeing 'lock order reversal' errors during boot on 11-CURRENT - 
r298793.  A sample error:


lock order reversal:
 1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
 2nd 0xfe01ca539400 bufwait (bufwait) @ 
/usr/src/sys/ufs/ffs/ffs_vnops.c:263

 3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
stack backtrace:
#0 0x80a94bf0 at witness_debugger+0x70
#1 0x80a94ae4 at witness_checkorder+0xe54
#2 0x80a0fdd6 at __lockmgr_args+0x4d6
#3 0x80ce9626 at ffs_lock+0xa6
[...snip...]

I'm not sure if this is even something I should report, but better safe 
than sorry, yes?


I'm attaching the full dmesg for more information.

Sincerely,

Will Brokenbourgh

Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r298793: Fri Apr 29 20:48:00 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz (3300.06-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7ffafbff
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended 
Features=0x27ab
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7625789440 (7272 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f10fb0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
atrtc0:  port 0x70-0x77 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0xf000-0xf03f mem 
0xf780-0xf7bf,0xe000-0xefff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
hdac0:  mem 0xf7d04000-0xf7d07fff irq 16 at 
device 3.0 on pci0
pci0:  at device 22.0 (no driver attached)
ehci0:  mem 0xf7d0b000-0xf7d0b3ff 
irq 16 at device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
hdac1:  mem 0xf7d0-0xf7d03fff irq 22 at 
device 27.0 on pci0
pcib1:  irq 16 at device 28.0 on pci0
pci1:  on pcib1
pcib2:  irq 18 at device 28.2 on pci0
pci2:  on pcib2
re0:  port 
0xe000-0xe0ff mem 0xf7c0-0xf7c00fff,0xf000-0xf0003fff irq 18 at device 
0.0 on pci2
re0: Using 1 MSI-X message
re0: ASPM disabled
re0: Chip rev. 0x4c00
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 
1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 40:8d:5c:38:04:9d
re0: netmap queues/slots: TX 1/256, RX 1/256
pcib3:  irq 19 at device 28.3 on pci0
pci3:  on pcib3
pcib4:  irq 19 at device 0.0 on pci3
pci4:  on pcib4
ehci1:  mem 0xf7d0a000-0xf7d0a3ff 
irq 23 at device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci1
isab0:  at device 31.0 on pci0
isa0:  on isab0
ahci0:  port 

Re: libarchive update SVN r299529 breaks "ezjail update"

[Martin Matuska]

That switch is "--insecure" and is supported in all libarchive versions
freebsd ever used.


On 15.05.2016 01:36, Ngie Cooper (yaneurabeya) wrote:
>> On May 14, 2016, at 16:29, Martin Matuska  wrote:
>>
>> Ian, we are here talking about cpio, not libarchive. The flag in
>> libarchive is not active by default.
>>
>> On 14.05.2016 22:08, Ian Lepore wrote:
>>> The real damage will happen to out-of-tree users.  I think this will
>>> impact our software updater for $work for example, and it has to work
>>> with both old and new versions of libarchive, and now the new version
>>> will require a flag that the old version will reject as unknown.
>>>
>>> Ick.
> Ian’s comment was valid.. cpio doesn’t recognize the new switch on older 
> versions, so something like cpio `cpio --help | grep -- switch && echo 
> switch` would need to be employed everywhere for backwards compatibility — ew.
> Thanks,
> -Ngie

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[Ngie Cooper (yaneurabeya)]

> On May 14, 2016, at 16:29, Martin Matuska  wrote:
> 
> Ian, we are here talking about cpio, not libarchive. The flag in
> libarchive is not active by default.
> 
> On 14.05.2016 22:08, Ian Lepore wrote:

>> The real damage will happen to out-of-tree users.  I think this will
>> impact our software updater for $work for example, and it has to work
>> with both old and new versions of libarchive, and now the new version
>> will require a flag that the old version will reject as unknown.
>> 
>> Ick.

Ian’s comment was valid.. cpio doesn’t recognize the new switch on older 
versions, so something like cpio `cpio --help | grep -- switch && echo switch` 
would need to be employed everywhere for backwards compatibility — ew.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[Ian Lepore]

On Sun, 2016-05-15 at 01:29 +0200, Martin Matuska wrote:
> Ian, we are here talking about cpio, not libarchive. The flag in
> libarchive is not active by default.
> 

Yes.  We use cpio for filesystem images, for historical reasons (such
as cpio's ability to encode device major/minor node numbers and other
stuff that doesn't really matter anymore, but the format is kinda cast
in stone now).

-- Ian

> 
> On 14.05.2016 22:08, Ian Lepore wrote:
> > On Sat, 2016-05-14 at 15:51 -0400, michael butler wrote:
> > >  From the looks of this, I think it's likely better to have the
> > > default 
> > > be "secure" and ezjail-admin use the "--insecure" flag as an
> > > explicit
> > > override. That's the only place I've noticed the need for it
> > > although
> > > I've not done an extensive search for any other instances in
> > > which it
> > > might be required,
> > > 
> > >   imb
> > > 
> > The real damage will happen to out-of-tree users.  I think this
> > will
> > impact our software updater for $work for example, and it has to
> > work
> > with both old and new versions of libarchive, and now the new
> > version
> > will require a flag that the old version will reject as unknown.
> > 
> > Ick.
> > 
> > -- Ian
> > 
> > > On 5/14/2016 3:46 PM, Tim Kientzle wrote:
> > > > A little history about this issue:
> > > > 
> > > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304
> > > > 
> > > > 
> > > > > On May 14, 2016, at 12:17 PM, Tim Kientzle 
> > > > > wrote:
> > > > > 
> > > > > Many people consider the traditional behavior to be a
> > > > > security
> > > > > risk, which is why this was changed.
> > > > > 
> > > > > FreeBSD is welcome to make --insecure the default on FreeBSD,
> > > > > but
> > > > > I'm reluctant to do that in the upstream libarchive project.
> > > > > 
> > > > > Tim
> > > > > 
> > > > > 
> > > > > > On May 12, 2016, at 8:54 AM, Martin Matuska  > > > > > >
> > > > > > wrote:
> > > > > > 
> > > > > > Looks like we have to remove line #174 from cpio/cpio.c:
> > > > > > cpio->extract_flags |=
> > > > > > ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
> > > > > > 
> > > > > > This breaks traditional cpio behavior.
> > > > > > 
> > > > > > Quoting Martin Matuska :
> > > > > > 
> > > > > > > Hi Michael, I have looked at the source and this is an
> > > > > > > intended change in 3.2.0.
> > > > > > > 
> > > > > > > An absolute path security check was added, cpio refuses
> > > > > > > to
> > > > > > > extract or copy over absolute paths. To do this anyway
> > > > > > > the "-
> > > > > > > -insecure" flag must be used.
> > > > > > > 
> > > > > > > Here is the commit:
> > > > > > > https://github.com/libarchive/libarchive/commit/593571577
> > > > > > > 06d4
> > > > > > > 7c365b2227739e17daba3607526
> > > > > > > 
> > > > > > > Quoting Michael Butler :
> > > > > > > 
> > > > > > > > It seems that today's libarchive update breaks cpio's
> > > > > > > > behaviour:
> > > > > > > > 
> > > > > > > > sudo ezjail-admin update -i -s /usr/src
> > > > > > > > 
> > > > > > > > [ .. ]
> > > > > > > > 
> > > > > > > > cd /usr/src/etc/..; install -o root -g wheel -m 444 
> > > > > > > >  COPYRIGHT
> > > > > > > > /usr/local/jails/fulljail/
> > > > > > > > install -o root -g wheel -m 444
> > > > > > > > /usr/src/etc/../sys/i386/conf/GENERIC.hints
> > > > > > > > /usr/local/jails/fulljail/boot/device.hints
> > > > > > > > /usr/local/jails/basejail/bincpio: bin: Path is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/chflagscpio: bin/chflags:
> > > > > > > > Path is
> > > > > > > > absolute: Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path
> > > > > > > > is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/chmodcpio: bin/chmod:
> > > > > > > > Path is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is
> > > > > > > > absolute: Unknown
> > > > > > > > error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/datecpio: bin/date: Path
> > > > > > > > is
> > > > > > > > absolute:
> > > > > > > > Unknown error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is
> > > > > > > > absolute: Unknown
> > > > > > > > error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is
> > > > > > > > absolute: Unknown
> > > > > > > > error: -1
> > > > > > > > 
> > > > > > > > /usr/local/jails/basejail/bin/domainnamecpio:
> > > > > > > > bin/domainname: Path is
> > > > > > > > absolute: Unknown error: -1
> > > > > > > > [ 

Re: libarchive update SVN r299529 breaks "ezjail update"

[Martin Matuska]

Ian, we are here talking about cpio, not libarchive. The flag in
libarchive is not active by default.


On 14.05.2016 22:08, Ian Lepore wrote:
> On Sat, 2016-05-14 at 15:51 -0400, michael butler wrote:
>>  From the looks of this, I think it's likely better to have the
>> default 
>> be "secure" and ezjail-admin use the "--insecure" flag as an explicit
>> override. That's the only place I've noticed the need for it although
>> I've not done an extensive search for any other instances in which it
>> might be required,
>>
>>  imb
>>
> The real damage will happen to out-of-tree users.  I think this will
> impact our software updater for $work for example, and it has to work
> with both old and new versions of libarchive, and now the new version
> will require a flag that the old version will reject as unknown.
>
> Ick.
>
> -- Ian
>
>> On 5/14/2016 3:46 PM, Tim Kientzle wrote:
>>> A little history about this issue:
>>>
>>> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304
>>>
>>>
 On May 14, 2016, at 12:17 PM, Tim Kientzle 
 wrote:

 Many people consider the traditional behavior to be a security
 risk, which is why this was changed.

 FreeBSD is welcome to make --insecure the default on FreeBSD, but
 I'm reluctant to do that in the upstream libarchive project.

 Tim


> On May 12, 2016, at 8:54 AM, Martin Matuska 
> wrote:
>
> Looks like we have to remove line #174 from cpio/cpio.c:
> cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
>
> This breaks traditional cpio behavior.
>
> Quoting Martin Matuska :
>
>> Hi Michael, I have looked at the source and this is an
>> intended change in 3.2.0.
>>
>> An absolute path security check was added, cpio refuses to
>> extract or copy over absolute paths. To do this anyway the "-
>> -insecure" flag must be used.
>>
>> Here is the commit:
>> https://github.com/libarchive/libarchive/commit/59357157706d4
>> 7c365b2227739e17daba3607526
>>
>> Quoting Michael Butler :
>>
>>> It seems that today's libarchive update breaks cpio's
>>> behaviour:
>>>
>>> sudo ezjail-admin update -i -s /usr/src
>>>
>>> [ .. ]
>>>
>>> cd /usr/src/etc/..; install -o root -g wheel -m 444 
>>>  COPYRIGHT
>>> /usr/local/jails/fulljail/
>>> install -o root -g wheel -m 444
>>> /usr/src/etc/../sys/i386/conf/GENERIC.hints
>>> /usr/local/jails/fulljail/boot/device.hints
>>> /usr/local/jails/basejail/bincpio: bin: Path is absolute:
>>> Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is
>>> absolute:
>>> Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/chflagscpio: bin/chflags:
>>> Path is
>>> absolute: Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is
>>> absolute:
>>> Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is
>>> absolute:
>>> Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is
>>> absolute: Unknown
>>> error: -1
>>>
>>> /usr/local/jails/basejail/bin/datecpio: bin/date: Path is
>>> absolute:
>>> Unknown error: -1
>>>
>>> /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is
>>> absolute: Unknown
>>> error: -1
>>>
>>> /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is
>>> absolute: Unknown
>>> error: -1
>>>
>>> /usr/local/jails/basejail/bin/domainnamecpio:
>>> bin/domainname: Path is
>>> absolute: Unknown error: -1
>>> [ .. etc. .. ]
>>
>>
>> Martin Matuska
>> FreeBSD committer
>> http://blog.vx.sk
>
>
> Martin Matuska
> FreeBSD committer
> http://blog.vx.sk
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "
>> freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice and CUPS

[Poul-Henning Kamp]

In message <20160514211909.gc1...@dendrobates.araler.com>, Sergey Manucharian w
rites:

>I've built kernel and world, cups and libreoffice were isnstalled as
>packages:

I just spent two hours finding out that shell pipes on -current(-ish),
r297556, returns EAGAIN when full:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209509

If, as I suspect, this affects any pipe, it has the potential to
break all sorts of things, including possibly this.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice and CUPS

[Sergey Manucharian]

Excerpts from Matthias Apitz's message from Sat 14-May-16 20:47:
> El día Saturday, May 14, 2016 a las 12:27:28PM -0600, Sergey Manucharian 
> escribió:
> 
> > After recent system update (I'm on FreeBSD 11.0-CURRENT r298793)
> > LibreOffice doesn't see CUPS printers. It shows only "Generic printer",
> > but doesn't actually print anything.
> 
> Libreoffice and cups are ports or packages made from ports, what are the 
> versions of
> them or your overall ports tree? And what do you mean by 'after recent
> update', have you just updated kernel and world? 

I've built kernel and world, cups and libreoffice were isnstalled as
packages:

cups-2.1.3_2
libreoffice-5.0.5_1

I've reisntalled them just in case. I can try building them from ports,
of course.

Thanks,
S.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[Ian Lepore]

On Sat, 2016-05-14 at 15:51 -0400, michael butler wrote:
>  From the looks of this, I think it's likely better to have the
> default 
> be "secure" and ezjail-admin use the "--insecure" flag as an explicit
> override. That's the only place I've noticed the need for it although
> I've not done an extensive search for any other instances in which it
> might be required,
> 
>   imb
> 

The real damage will happen to out-of-tree users.  I think this will
impact our software updater for $work for example, and it has to work
with both old and new versions of libarchive, and now the new version
will require a flag that the old version will reject as unknown.

Ick.

-- Ian

> On 5/14/2016 3:46 PM, Tim Kientzle wrote:
> > A little history about this issue:
> > 
> > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304
> > 
> > 
> > > On May 14, 2016, at 12:17 PM, Tim Kientzle 
> > > wrote:
> > > 
> > > Many people consider the traditional behavior to be a security
> > > risk, which is why this was changed.
> > > 
> > > FreeBSD is welcome to make --insecure the default on FreeBSD, but
> > > I'm reluctant to do that in the upstream libarchive project.
> > > 
> > > Tim
> > > 
> > > 
> > > > On May 12, 2016, at 8:54 AM, Martin Matuska 
> > > > wrote:
> > > > 
> > > > Looks like we have to remove line #174 from cpio/cpio.c:
> > > > cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
> > > > 
> > > > This breaks traditional cpio behavior.
> > > > 
> > > > Quoting Martin Matuska :
> > > > 
> > > > > Hi Michael, I have looked at the source and this is an
> > > > > intended change in 3.2.0.
> > > > > 
> > > > > An absolute path security check was added, cpio refuses to
> > > > > extract or copy over absolute paths. To do this anyway the "-
> > > > > -insecure" flag must be used.
> > > > > 
> > > > > Here is the commit:
> > > > > https://github.com/libarchive/libarchive/commit/59357157706d4
> > > > > 7c365b2227739e17daba3607526
> > > > > 
> > > > > Quoting Michael Butler :
> > > > > 
> > > > > > It seems that today's libarchive update breaks cpio's
> > > > > > behaviour:
> > > > > > 
> > > > > > sudo ezjail-admin update -i -s /usr/src
> > > > > > 
> > > > > > [ .. ]
> > > > > > 
> > > > > > cd /usr/src/etc/..; install -o root -g wheel -m 444 
> > > > > >  COPYRIGHT
> > > > > > /usr/local/jails/fulljail/
> > > > > > install -o root -g wheel -m 444
> > > > > > /usr/src/etc/../sys/i386/conf/GENERIC.hints
> > > > > > /usr/local/jails/fulljail/boot/device.hints
> > > > > > /usr/local/jails/basejail/bincpio: bin: Path is absolute:
> > > > > > Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is
> > > > > > absolute:
> > > > > > Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/chflagscpio: bin/chflags:
> > > > > > Path is
> > > > > > absolute: Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is
> > > > > > absolute:
> > > > > > Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is
> > > > > > absolute:
> > > > > > Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is
> > > > > > absolute: Unknown
> > > > > > error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/datecpio: bin/date: Path is
> > > > > > absolute:
> > > > > > Unknown error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is
> > > > > > absolute: Unknown
> > > > > > error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is
> > > > > > absolute: Unknown
> > > > > > error: -1
> > > > > > 
> > > > > > /usr/local/jails/basejail/bin/domainnamecpio:
> > > > > > bin/domainname: Path is
> > > > > > absolute: Unknown error: -1
> > > > > > [ .. etc. .. ]
> > > > > 
> > > > > 
> > > > > 
> > > > > Martin Matuska
> > > > > FreeBSD committer
> > > > > http://blog.vx.sk
> > > > 
> > > > 
> > > > 
> > > > Martin Matuska
> > > > FreeBSD committer
> > > > http://blog.vx.sk
> > > 
> > 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[michael butler]

From the looks of this, I think it's likely better to have the default 
be "secure" and ezjail-admin use the "--insecure" flag as an explicit 
override. That's the only place I've noticed the need for it although 
I've not done an extensive search for any other instances in which it 
might be required,


imb

On 5/14/2016 3:46 PM, Tim Kientzle wrote:

A little history about this issue:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304



On May 14, 2016, at 12:17 PM, Tim Kientzle  wrote:

Many people consider the traditional behavior to be a security risk, which is 
why this was changed.

FreeBSD is welcome to make --insecure the default on FreeBSD, but I'm reluctant 
to do that in the upstream libarchive project.

Tim



On May 12, 2016, at 8:54 AM, Martin Matuska  wrote:

Looks like we have to remove line #174 from cpio/cpio.c:
cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;

This breaks traditional cpio behavior.

Quoting Martin Matuska :


Hi Michael, I have looked at the source and this is an intended change in 3.2.0.

An absolute path security check was added, cpio refuses to extract or copy over absolute 
paths. To do this anyway the "--insecure" flag must be used.

Here is the commit:
https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526

Quoting Michael Butler :


It seems that today's libarchive update breaks cpio's behaviour:

sudo ezjail-admin update -i -s /usr/src

[ .. ]

cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
/usr/local/jails/fulljail/
install -o root -g wheel -m 444
/usr/src/etc/../sys/i386/conf/GENERIC.hints
/usr/local/jails/fulljail/boot/device.hints
/usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1

/usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
Unknown error: -1

/usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
absolute: Unknown error: -1

/usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
Unknown error: -1

/usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
Unknown error: -1

/usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
error: -1

/usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
Unknown error: -1

/usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
error: -1

/usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
error: -1

/usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
absolute: Unknown error: -1
[ .. etc. .. ]




Martin Matuska
FreeBSD committer
http://blog.vx.sk




Martin Matuska
FreeBSD committer
http://blog.vx.sk





___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[Tim Kientzle]

Many people consider the traditional behavior to be a security risk, which is 
why this was changed.

FreeBSD is welcome to make --insecure the default on FreeBSD, but I'm reluctant 
to do that in the upstream libarchive project.

Tim


> On May 12, 2016, at 8:54 AM, Martin Matuska  wrote:
> 
> Looks like we have to remove line #174 from cpio/cpio.c:
> cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
> 
> This breaks traditional cpio behavior.
> 
> Quoting Martin Matuska :
> 
>> Hi Michael, I have looked at the source and this is an intended change in 
>> 3.2.0.
>> 
>> An absolute path security check was added, cpio refuses to extract or copy 
>> over absolute paths. To do this anyway the "--insecure" flag must be used.
>> 
>> Here is the commit:
>> https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526
>> 
>> Quoting Michael Butler :
>> 
>>> It seems that today's libarchive update breaks cpio's behaviour:
>>> 
>>> sudo ezjail-admin update -i -s /usr/src
>>> 
>>> [ .. ]
>>> 
>>> cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
>>> /usr/local/jails/fulljail/
>>> install -o root -g wheel -m 444
>>> /usr/src/etc/../sys/i386/conf/GENERIC.hints
>>> /usr/local/jails/fulljail/boot/device.hints
>>> /usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
>>> absolute: Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
>>> absolute: Unknown error: -1
>>> [ .. etc. .. ]
>> 
>> 
>> 
>> Martin Matuska
>> FreeBSD committer
>> http://blog.vx.sk
> 
> 
> 
> Martin Matuska
> FreeBSD committer
> http://blog.vx.sk

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libarchive update SVN r299529 breaks "ezjail update"

[Tim Kientzle]

A little history about this issue:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304


> On May 14, 2016, at 12:17 PM, Tim Kientzle  wrote:
> 
> Many people consider the traditional behavior to be a security risk, which is 
> why this was changed.
> 
> FreeBSD is welcome to make --insecure the default on FreeBSD, but I'm 
> reluctant to do that in the upstream libarchive project.
> 
> Tim
> 
> 
>> On May 12, 2016, at 8:54 AM, Martin Matuska  wrote:
>> 
>> Looks like we have to remove line #174 from cpio/cpio.c:
>> cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
>> 
>> This breaks traditional cpio behavior.
>> 
>> Quoting Martin Matuska :
>> 
>>> Hi Michael, I have looked at the source and this is an intended change in 
>>> 3.2.0.
>>> 
>>> An absolute path security check was added, cpio refuses to extract or copy 
>>> over absolute paths. To do this anyway the "--insecure" flag must be used.
>>> 
>>> Here is the commit:
>>> https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526
>>> 
>>> Quoting Michael Butler :
>>> 
 It seems that today's libarchive update breaks cpio's behaviour:
 
 sudo ezjail-admin update -i -s /usr/src
 
 [ .. ]
 
 cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
 /usr/local/jails/fulljail/
 install -o root -g wheel -m 444
 /usr/src/etc/../sys/i386/conf/GENERIC.hints
 /usr/local/jails/fulljail/boot/device.hints
 /usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1
 
 /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
 Unknown error: -1
 
 /usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
 absolute: Unknown error: -1
 
 /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
 Unknown error: -1
 
 /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
 Unknown error: -1
 
 /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
 error: -1
 
 /usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
 Unknown error: -1
 
 /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
 error: -1
 
 /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
 error: -1
 
 /usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
 absolute: Unknown error: -1
 [ .. etc. .. ]
>>> 
>>> 
>>> 
>>> Martin Matuska
>>> FreeBSD committer
>>> http://blog.vx.sk
>> 
>> 
>> 
>> Martin Matuska
>> FreeBSD committer
>> http://blog.vx.sk
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice and CUPS

[Matthias Apitz]

El día Saturday, May 14, 2016 a las 12:27:28PM -0600, Sergey Manucharian 
escribió:

> After recent system update (I'm on FreeBSD 11.0-CURRENT r298793)
> LibreOffice doesn't see CUPS printers. It shows only "Generic printer",
> but doesn't actually print anything.

Libreoffice and cups are ports or packages made from ports, what are the 
versions of
them or your overall ports tree? And what do you mean by 'after recent
update', have you just updated kernel and world? 

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
8 мая 1945: Спасибо, Советского Союза!  --  May 8, 1945: Thank you, Soviet 
Union! 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

LibreOffice and CUPS

[Sergey Manucharian]

After recent system update (I'm on FreeBSD 11.0-CURRENT r298793)
LibreOffice doesn't see CUPS printers. It shows only "Generic printer",
but doesn't actually print anything.

Thanks for advices!

S.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Issue mentioned on questions list

[Allan Jude]

On 2016-05-14 08:49, Mehmet Erol Sanliturk wrote:
> On Fri, May 13, 2016 at 9:50 PM, Shane Ambler  wrote:
> 
>> I'm not expecting a reply to this, it was something that come up
>> discussing building custom kernels.
>>
>> Just wondering if someone may be interested in looking at the
>> possibility of changing username length to a sysctl.
>>
>> As the number of people using computers is increasing, it is now
>> common for web sites/mail servers to use your full email as your
>> username, keeping that consistent through all username usage doesn't
>> seem like an unreasonable request. I would expect a username length
>> sysctl value would only be allowed to be set in the loader.conf at boot
>> time, similar to zfs.arc_max
>>
>>
>>
> 
> Over time , I want to generate a FreeBSD live CD/DVD with root/user
> password entered on boot ( i.e. , no prerecorded passwords ) from a 2D bar
> code or from a USB stick or from an SD card with sufficiently long length
> defined in the kernel routines .
> 
> This feature also may be used for remote logins .
> 
> Such a long password generated by a program by random character selection
> from a character alphabet  is impossible to estimate .
> 
> 
> This "password name length" feature may also be considered along side with
> "user name length" .
> 
> 
> Mehmet Erol Sanliturk
> 
> 
> 
> 
> 
>>  Forwarded Message 
>> Subject: Re: Custom kernel for NAT and PF ?
>> Date: Sat, 14 May 2016 13:58:56 +0930
>> From: Shane Ambler 
>> To: Doug McIntyre , FreeBSD Questions <
>> freebsd-questi...@freebsd.org>
>>
>> On 14/05/2016 04:40, Doug McIntyre wrote:
>>
>>> On Fri, May 13, 2016 at 02:04:55PM +0930, Shane Ambler wrote:
>>>
 Now you only need to compile a custom kernel if you want to use newer
>
 features.

>>> ...
>>>
>>> Unfortunately, I have two situations where that isn't true.
>>>
>>> For the first, I wish that just loading the PPS drivers enabled the
>>> PPS_SYNC option in the kernel, but it doesn't seem to. (if there is
>>> a way to enable 'option PPS_SYNC' with a generic kernel I'd like to know,
>>> but my experients didn't lead me that working. I still have to compile
>>> the kernel for my GPS connected NTP servers. Which makes me wonder why
>>> the PPS drivers are a kernel loadable object.
>>>
>>
>> I would report that as a bug and see if it can be improved.
>>
>> The second is that the username handling is still limited to 32-bytes,
>>> which really cramps my logins for '
>>> billyjoebobu...@somesillydomainname.com'
>>> so I have to build a custom kernel with longer usernames patched for
>>> the systems that need to deal with system logins like that.
>>>
>>
>> While I don't have that issue, it does sound like an old time
>> limitation that should be considered for rework. Maybe it could be
>> made into an adjustable sysctl.
>>
>> --
>> FreeBSD - the place to B...Software Developing
>>
>> Shane Ambler
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

The maximum length of the password is determined by the hashing
algorithm used to hash the password.

The now default sha512crypt has no upper limit at all.

-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Issue mentioned on questions list

[Mehmet Erol Sanliturk]

On Fri, May 13, 2016 at 9:50 PM, Shane Ambler  wrote:

> I'm not expecting a reply to this, it was something that come up
> discussing building custom kernels.
>
> Just wondering if someone may be interested in looking at the
> possibility of changing username length to a sysctl.
>
> As the number of people using computers is increasing, it is now
> common for web sites/mail servers to use your full email as your
> username, keeping that consistent through all username usage doesn't
> seem like an unreasonable request. I would expect a username length
> sysctl value would only be allowed to be set in the loader.conf at boot
> time, similar to zfs.arc_max
>
>
>

Over time , I want to generate a FreeBSD live CD/DVD with root/user
password entered on boot ( i.e. , no prerecorded passwords ) from a 2D bar
code or from a USB stick or from an SD card with sufficiently long length
defined in the kernel routines .

This feature also may be used for remote logins .

Such a long password generated by a program by random character selection
from a character alphabet  is impossible to estimate .


This "password name length" feature may also be considered along side with
"user name length" .


Mehmet Erol Sanliturk





>  Forwarded Message 
> Subject: Re: Custom kernel for NAT and PF ?
> Date: Sat, 14 May 2016 13:58:56 +0930
> From: Shane Ambler 
> To: Doug McIntyre , FreeBSD Questions <
> freebsd-questi...@freebsd.org>
>
> On 14/05/2016 04:40, Doug McIntyre wrote:
>
>> On Fri, May 13, 2016 at 02:04:55PM +0930, Shane Ambler wrote:
>>
>>> Now you only need to compile a custom kernel if you want to use newer

>>> features.
>>>
>> ...
>>
>> Unfortunately, I have two situations where that isn't true.
>>
>> For the first, I wish that just loading the PPS drivers enabled the
>> PPS_SYNC option in the kernel, but it doesn't seem to. (if there is
>> a way to enable 'option PPS_SYNC' with a generic kernel I'd like to know,
>> but my experients didn't lead me that working. I still have to compile
>> the kernel for my GPS connected NTP servers. Which makes me wonder why
>> the PPS drivers are a kernel loadable object.
>>
>
> I would report that as a bug and see if it can be improved.
>
> The second is that the username handling is still limited to 32-bytes,
>> which really cramps my logins for '
>> billyjoebobu...@somesillydomainname.com'
>> so I have to build a custom kernel with longer usernames patched for
>> the systems that need to deal with system logins like that.
>>
>
> While I don't have that issue, it does sound like an old time
> limitation that should be considered for rework. Maybe it could be
> made into an adjustable sysctl.
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"