Re: Building OpenBSD 6.0 -stable - Error
On 09/03/16 11:32, Harald Dunkel wrote: On 09/03/16 12:40, Ted Unangst wrote: Teno Deuter wrote: installed a fresh 6.0 AMD64 and tried to build 'stable' from source. Here is what I did as 'root' (as described in: http://www.openbsd.org/stable.html): export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs cd /usr; cvs checkout -P -rOPENBSD_6_0 src there's some repo surgery in progress. it should be fixed eventually. What exactly does this mean? It means that something went wrong, and steps were being taken to fix it. Not very often, cvs has problems and getting good copies of stuff doesn't work. This is always noticed and repaired fairly quickly. Also, if a repository is down, people have noticed it and are working on it, so messages to @misc such as "I can't update from xxx" are somewhat useless. The ecosystem for distributing software is not perfect. When you find a problem, wait, and try again. Repeat if needed. --STeve Andre'
Re: rdomain incompatible with NSD ? (OpenBSD 6)
Bob Jones(r.a.n.d.o.m.d.e.v.4+openbsdm...@gmail.com) on 2016.09.03 19:11:41 +0100: > Hi, > > Not sure if its a feature or a bug. ;-) > > OpenBSD my.example.com 6.0 GENERIC.MP#2319 amd64 > > Relevant bit of /var/nsd/etc/nsd.conf: > ip-address: 10.1.2.3 > > > $ cat /etc/hostname.vmx1 > rdomain 1 > inet 10.1.2.3 255.255.255.224 > !route -T1 add default 10.1.2.65 > > The above yields : > Sep 3 18:35:40 my nsd[35324]: nsd starting (NSD 4.1.10) > Sep 3 18:35:40 my nsd[35324]: can't bind udp socket: Can't assign > requested address > Sep 3 18:35:40 my nsd[35324]: server initialization failed, nsd could > not be started > > Commenting out or removing the rdomain and route lines yields: > Sep 3 18:40:05 my nsd[40514]: nsd starting (NSD 4.1.10) > Sep 3 18:40:05 my nsd[36692]: nsd started (NSD 4.1.10), pid 17346 Relevant bit of a solution: set nsd_rtable=1 in /etc/rc.conf.local
Re: not exactly (Re: systrace removed? Why?)
if someone's interested, here a list of fs differences between 6.0 upgraded from 5.9, and 6.0 install, i found, with some obvious differences like smtpd spool or sysmerge backups removed (amd64/qemu): http://pastebin.com/raw/VPkdbvxy (text/plain) (not pasting because of long lines) hth
Re: Removal of old libraries
Thank you very much, all! Giving it a shot now. On Sat, Sep 3, 2016, 16:35 Juan Francisco Cantero Hurtadowrote: > On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote: > > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > > early May 2011. I've been quite happy with how it works, and I've been > > doing bsd.rd upgrades and M:Tier binary updates ever since. > > > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with > an > > atime of my last level 0 dump several months ago. Looks like pkg_add -u > > left a bunch of stuff behind. Is there a recommended way to clean this > > stuff up, or should I just start chopping away with something like: > > > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > > > (after a new level 0 dump, obviously...) > > > > pkg_add sysclean > > man sysclean > > -- > Juan Francisco Cantero Hurtado http://juanfra.info
Re: Removal of old libraries
On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote: > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > early May 2011. I've been quite happy with how it works, and I've been > doing bsd.rd upgrades and M:Tier binary updates ever since. > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an > atime of my last level 0 dump several months ago. Looks like pkg_add -u > left a bunch of stuff behind. Is there a recommended way to clean this > stuff up, or should I just start chopping away with something like: > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > (after a new level 0 dump, obviously...) > pkg_add sysclean man sysclean -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Removal of old libraries
pkg_delete -a El 3 sept. 2016 3:12 PM, Ax0nescribió: > > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in > early May 2011. I've been quite happy with how it works, and I've been > doing bsd.rd upgrades and M:Tier binary updates ever since. > > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an > atime of my last level 0 dump several months ago. Looks like pkg_add -u > left a bunch of stuff behind. Is there a recommended way to clean this > stuff up, or should I just start chopping away with something like: > > find /usr/local/lib -type f -atime +90 | doas xargs rm > > (after a new level 0 dump, obviously...)
Removal of old libraries
I've got a Toshiba NB305 netbook that's been my daily-use laptop for more than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in early May 2011. I've been quite happy with how it works, and I've been doing bsd.rd upgrades and M:Tier binary updates ever since. There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an atime of my last level 0 dump several months ago. Looks like pkg_add -u left a bunch of stuff behind. Is there a recommended way to clean this stuff up, or should I just start chopping away with something like: find /usr/local/lib -type f -atime +90 | doas xargs rm (after a new level 0 dump, obviously...)
Re: rdomain incompatible with NSD ? (OpenBSD 6)
You have to start nsd in rdomain 1. Von meinem Samsung Galaxy Smartphone gesendet. Ursprüngliche Nachricht Von: Bob JonesDatum: 03.09.16 20:13 (GMT+01:00) An: misc@openbsd.org Betreff: rdomain incompatible with NSD ? (OpenBSD 6)
rdomain incompatible with NSD ? (OpenBSD 6)
Hi, Not sure if its a feature or a bug. ;-) OpenBSD my.example.com 6.0 GENERIC.MP#2319 amd64 Relevant bit of /var/nsd/etc/nsd.conf: ip-address: 10.1.2.3 $ cat /etc/hostname.vmx1 rdomain 1 inet 10.1.2.3 255.255.255.224 !route -T1 add default 10.1.2.65 The above yields : Sep 3 18:35:40 my nsd[35324]: nsd starting (NSD 4.1.10) Sep 3 18:35:40 my nsd[35324]: can't bind udp socket: Can't assign requested address Sep 3 18:35:40 my nsd[35324]: server initialization failed, nsd could not be started Commenting out or removing the rdomain and route lines yields: Sep 3 18:40:05 my nsd[40514]: nsd starting (NSD 4.1.10) Sep 3 18:40:05 my nsd[36692]: nsd started (NSD 4.1.10), pid 17346
Re: not exactly (Re: systrace removed? Why?)
Sent from my iPhone On Sep 3, 2016, at 12:46 PM, Michal Bozonwrote: >> good(?) news: sysmerge is gone in 6.0 >> but not removed by 5.9 to 6.0 uprade process. > > s/sysmerge/systrace/ > pledge()
Re: not exactly (Re: systrace removed? Why?)
> > good(?) news: sysmerge is gone in 6.0 > > but not removed by 5.9 to 6.0 uprade process. > > > > I really have a hard time understanding what you're trying to point out. > > Yes, systrace is gone, but it's an ordinary binary that does no harm, > feel free to remove it if it makes you feel better. > > sysmerge isn't gone, but it is executed automatically if you use a > bsd.rd upgrade, hence it's only mentioned in the manual upgrade process. ok, never mind, i have just spotted it when comparing fs trees of freshly installed 6.0 and freshly installed/upgraded 5.9/6.0 .. and made sure to report it immediately, since the removal of systrace is advertised as a security enhancement :)
Re: not exactly (Re: systrace removed? Why?)
> good(?) news: sysmerge is gone in 6.0 > but not removed by 5.9 to 6.0 uprade process. s/sysmerge/systrace/
Re: not exactly (Re: systrace removed? Why?)
On Sat, Sep 03, 2016 at 05:37:22PM +, Michal Bozon wrote: > > Why? > > good(?) news: sysmerge is gone in 6.0 > but not removed by 5.9 to 6.0 uprade process. > I really have a hard time understanding what you're trying to point out. Yes, systrace is gone, but it's an ordinary binary that does no harm, feel free to remove it if it makes you feel better. sysmerge isn't gone, but it is executed automatically if you use a bsd.rd upgrade, hence it's only mentioned in the manual upgrade process.
not exactly (Re: systrace removed? Why?)
> Why? good(?) news: sysmerge is gone in 6.0 but not removed by 5.9 to 6.0 uprade process.
Re: Building OpenBSD 6.0 -stable - Error
Yes, the repos should be done with their surgery now. Please let us know if you still see issues. On 2016 Sep 03 (Sat) at 13:11:42 +0200 (+0200), Teno Deuter wrote: :meaning I shall try at a later time? : :Thank you : :On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangstwrote: :> Teno Deuter wrote: :>> installed a fresh 6.0 AMD64 and tried to build 'stable' from source. :>> :>> Here is what I did as 'root' (as described in: :>> http://www.openbsd.org/stable.html): :>> :>> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs :>> cd /usr; cvs checkout -P -rOPENBSD_6_0 src :> :> there's some repo surgery in progress. it should be fixed eventually. : -- Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account.
Re: Building OpenBSD 6.0 -stable - Error
On 09/03/16 12:40, Ted Unangst wrote: > Teno Deuter wrote: >> installed a fresh 6.0 AMD64 and tried to build 'stable' from source. >> >> Here is what I did as 'root' (as described in: >> http://www.openbsd.org/stable.html): >> >> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs >> cd /usr; cvs checkout -P -rOPENBSD_6_0 src > > there's some repo surgery in progress. it should be fixed eventually. > What exactly does this mean?
Re: Building OpenBSD 6.0 -stable - Error
Hello Teno, I have successfully updated five OpenBSD 5.9 to 6.0 on release day , following https://www.openbsd.org/faq/upgrade60.html After, I rebuilt all them to stable branch from: $ cd /usr $ cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs get -rOPENBSD_6_0 -P src Was magical as expected. Regards, 2016-09-03 8:11 GMT-03:00 Teno Deuter: > meaning I shall try at a later time? > > Thank you > > On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangst wrote: > > Teno Deuter wrote: > >> installed a fresh 6.0 AMD64 and tried to build 'stable' from source. > >> > >> Here is what I did as 'root' (as described in: > >> http://www.openbsd.org/stable.html): > >> > >> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs > >> cd /usr; cvs checkout -P -rOPENBSD_6_0 src > > > > there's some repo surgery in progress. it should be fixed eventually.
Re: might it be better to have three paths lists
Split your program. Stricter privilege separation. Replace thread with fork, you will have self contained program unit. An overflow in one won't affect the other. And each piece will have tighter pledge. 2016-09-03 12:37 GMT+02:00 Luke Small: > If a program requires studio, wpath, rpath, dns, and inet. It spawns > multiple threads. The socket binding thread is taken over, runs arbitrary > code that overflows a buffer of the thread listening to a pipe with rpath > and stdio permissions it reads the binary of an executable the company wants > to remain private, but is on the paths list, which gives the process > unintentional read permissions and sends it to the attacker. > Because we know everybody writes perfect code. With finer grained paths > permissions, it is possible to gain even better control amidst really well > pledged and privilege separated programs(even if they are imperfectly > bounded), it may be possible to have a slightly more complicated paths setup > with less privilege separation, written by programmers that spend a bit less > time with privilege separation, to meet deadlines and achieve comparable > results. > > > On Sat, Sep 3, 2016, 04:41 ludovic coues wrote: >> >> 2016-09-03 11:04 GMT+02:00 Luke Small : >> > >> > >> > Sorry I was in the middle of something, but pledge can be a broad >> > brush, >> > unless you are dealing with one file, whether it is executed, read, or >> > written and giving per process file permissions sounds pretty neat, and >> > it >> > might just be a little simpler than making new users for each subset of >> > privileges, populating each chrooted home folder with a specific set of >> > permissions (as is what appears to me to have happened with pkg_add). >> > Since >> > pledge's promises can make it where you can execute a file without read >> > permission, it seems ideal to continue that tradition with the paths >> > >> > On Sat, Sep 3, 2016, 03:07 Luke Small wrote: >> >> >> >> In pledge, presumably there will be an accessible paths list. Maybe you >> >> grant a process root access, and you need to read a file which is only >> >> granted by root access, and you need write access for another file, so >> >> the >> >> pledge permissions reflect that. On the presumed current path, you >> >> would >> >> leave write access for the first file and maybe you don't need the >> >> process >> >> to have read permissions on an execl() program. You can prohibit your >> >> process from reading your software or binary, even if it may have >> >> permissions to do so. >> >> >> >> That's not a specific use case. >> Either you should provide a patch or an exemple of a real program that >> is limited by the current design of pledge. >> >> Currently, if you want a program that can only read a file, you pledge >> rpath. If you want the ability to exec file, you pledge exec. >> >> If you want a program that can exec a set of file and write in >> another, either you run your program as a user and group that can't >> write the set of file you want to exec (W^X) or you write two program, >> one pledging for write the other for read. >> >> There following paper have an exemple of how the second design can be >> done. >> http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html >> >> >> -- >> >> Cordialement, Coues Ludovic >> +336 148 743 42 -- Cordialement, Coues Ludovic +336 148 743 42
Re: might it be better to have three paths lists
Wow, Luke you are the man. > Probably right, if they were pushing strong release dates, they'd go with > freebsd or linux > > On Sat, Sep 3, 2016, 05:44 Theo de Raadtwrote: > > > Not a strong requirement. > > > > > If a program requires studio, wpath, rpath, dns, and inet. It spawns > > > multiple threads. The socket binding thread is taken over, runs arbitrary > > > code that overflows a buffer of the thread listening to a pipe with rpath > > > and stdio permissions it reads the binary of an executable the company > > > wants to remain private, but is on the paths list, which gives the > > process > > > unintentional read permissions and sends it to the attacker. > > > Because we know everybody writes perfect code. With finer grained paths > > > permissions, it is possible to gain even better control amidst really > > well > > > pledged and privilege separated programs(even if they are imperfectly > > > bounded), it may be possible to have a slightly more complicated paths > > > setup with less privilege separation, written by programmers that spend a > > > bit less time with privilege separation, to meet deadlines and achieve > > > comparable results. > > > > > > On Sat, Sep 3, 2016, 04:41 ludovic coues wrote: > > > > > > > 2016-09-03 11:04 GMT+02:00 Luke Small : > > > > > > > > > > > > > > > Sorry I was in the middle of something, but pledge can be a broad > > brush, > > > > > unless you are dealing with one file, whether it is executed, read, > > or > > > > > written and giving per process file permissions sounds pretty neat, > > and > > > > it > > > > > might just be a little simpler than making new users for each subset > > of > > > > > privileges, populating each chrooted home folder with a specific set > > of > > > > > permissions (as is what appears to me to have happened with pkg_add). > > > > Since > > > > > pledge's promises can make it where you can execute a file without > > read > > > > > permission, it seems ideal to continue that tradition with the paths > > > > > > > > > > On Sat, Sep 3, 2016, 03:07 Luke Small > > wrote: > > > > >> > > > > >> In pledge, presumably there will be an accessible paths list. Maybe > > you > > > > >> grant a process root access, and you need to read a file which is > > only > > > > >> granted by root access, and you need write access for another file, > > so > > > > the > > > > >> pledge permissions reflect that. On the presumed current path, you > > would > > > > >> leave write access for the first file and maybe you don't need the > > > > process > > > > >> to have read permissions on an execl() program. You can prohibit > > your > > > > >> process from reading your software or binary, even if it may have > > > > >> permissions to do so. > > > > >> > > > > > > > > That's not a specific use case. > > > > Either you should provide a patch or an exemple of a real program that > > > > is limited by the current design of pledge. > > > > > > > > Currently, if you want a program that can only read a file, you pledge > > > > rpath. If you want the ability to exec file, you pledge exec. > > > > > > > > If you want a program that can exec a set of file and write in > > > > another, either you run your program as a user and group that can't > > > > write the set of file you want to exec (W^X) or you write two program, > > > > one pledging for write the other for read. > > > > > > > > There following paper have an exemple of how the second design can be > > done. > > > > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html > > > > > > > > > > > > -- > > > > > > > > Cordialement, Coues Ludovic > > > > +336 148 743 42 > > > > > > > > > --94eb2c07d10429a200053b98ce09 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Probably right, if they were pushing strong release dates, t= > heyd go with freebsd or linux > On Sat, Sep 3, 2016, 05:44 = > Theo de Raadt mailto:dera...@openbsd.org;>dera...@openbsd.or= > g wrote: :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a strong requi= > rement. > > If a program requires studio, wpath, rpath, dns, and inet. It
Re: Building OpenBSD 6.0 -stable - Error
meaning I shall try at a later time? Thank you On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangstwrote: > Teno Deuter wrote: >> installed a fresh 6.0 AMD64 and tried to build 'stable' from source. >> >> Here is what I did as 'root' (as described in: >> http://www.openbsd.org/stable.html): >> >> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs >> cd /usr; cvs checkout -P -rOPENBSD_6_0 src > > there's some repo surgery in progress. it should be fixed eventually.
Re: might it be better to have three paths lists
Not a strong requirement. > If a program requires studio, wpath, rpath, dns, and inet. It spawns > multiple threads. The socket binding thread is taken over, runs arbitrary > code that overflows a buffer of the thread listening to a pipe with rpath > and stdio permissions it reads the binary of an executable the company > wants to remain private, but is on the paths list, which gives the process > unintentional read permissions and sends it to the attacker. > Because we know everybody writes perfect code. With finer grained paths > permissions, it is possible to gain even better control amidst really well > pledged and privilege separated programs(even if they are imperfectly > bounded), it may be possible to have a slightly more complicated paths > setup with less privilege separation, written by programmers that spend a > bit less time with privilege separation, to meet deadlines and achieve > comparable results. > > On Sat, Sep 3, 2016, 04:41 ludovic coueswrote: > > > 2016-09-03 11:04 GMT+02:00 Luke Small : > > > > > > > > > Sorry I was in the middle of something, but pledge can be a broad brush, > > > unless you are dealing with one file, whether it is executed, read, or > > > written and giving per process file permissions sounds pretty neat, and > > it > > > might just be a little simpler than making new users for each subset of > > > privileges, populating each chrooted home folder with a specific set of > > > permissions (as is what appears to me to have happened with pkg_add). > > Since > > > pledge's promises can make it where you can execute a file without read > > > permission, it seems ideal to continue that tradition with the paths > > > > > > On Sat, Sep 3, 2016, 03:07 Luke Small wrote: > > >> > > >> In pledge, presumably there will be an accessible paths list. Maybe you > > >> grant a process root access, and you need to read a file which is only > > >> granted by root access, and you need write access for another file, so > > the > > >> pledge permissions reflect that. On the presumed current path, you would > > >> leave write access for the first file and maybe you don't need the > > process > > >> to have read permissions on an execl() program. You can prohibit your > > >> process from reading your software or binary, even if it may have > > >> permissions to do so. > > >> > > > > That's not a specific use case. > > Either you should provide a patch or an exemple of a real program that > > is limited by the current design of pledge. > > > > Currently, if you want a program that can only read a file, you pledge > > rpath. If you want the ability to exec file, you pledge exec. > > > > If you want a program that can exec a set of file and write in > > another, either you run your program as a user and group that can't > > write the set of file you want to exec (W^X) or you write two program, > > one pledging for write the other for read. > > > > There following paper have an exemple of how the second design can be done. > > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html > > > > > > -- > > > > Cordialement, Coues Ludovic > > +336 148 743 42
Re: Building OpenBSD 6.0 -stable - Error
Teno Deuter wrote: > installed a fresh 6.0 AMD64 and tried to build 'stable' from source. > > Here is what I did as 'root' (as described in: > http://www.openbsd.org/stable.html): > > export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs > cd /usr; cvs checkout -P -rOPENBSD_6_0 src there's some repo surgery in progress. it should be fixed eventually.
Re: might it be better to have three paths lists
If a program requires studio, wpath, rpath, dns, and inet. It spawns multiple threads. The socket binding thread is taken over, runs arbitrary code that overflows a buffer of the thread listening to a pipe with rpath and stdio permissions it reads the binary of an executable the company wants to remain private, but is on the paths list, which gives the process unintentional read permissions and sends it to the attacker. Because we know everybody writes perfect code. With finer grained paths permissions, it is possible to gain even better control amidst really well pledged and privilege separated programs(even if they are imperfectly bounded), it may be possible to have a slightly more complicated paths setup with less privilege separation, written by programmers that spend a bit less time with privilege separation, to meet deadlines and achieve comparable results. On Sat, Sep 3, 2016, 04:41 ludovic coueswrote: > 2016-09-03 11:04 GMT+02:00 Luke Small : > > > > > > Sorry I was in the middle of something, but pledge can be a broad brush, > > unless you are dealing with one file, whether it is executed, read, or > > written and giving per process file permissions sounds pretty neat, and > it > > might just be a little simpler than making new users for each subset of > > privileges, populating each chrooted home folder with a specific set of > > permissions (as is what appears to me to have happened with pkg_add). > Since > > pledge's promises can make it where you can execute a file without read > > permission, it seems ideal to continue that tradition with the paths > > > > On Sat, Sep 3, 2016, 03:07 Luke Small wrote: > >> > >> In pledge, presumably there will be an accessible paths list. Maybe you > >> grant a process root access, and you need to read a file which is only > >> granted by root access, and you need write access for another file, so > the > >> pledge permissions reflect that. On the presumed current path, you would > >> leave write access for the first file and maybe you don't need the > process > >> to have read permissions on an execl() program. You can prohibit your > >> process from reading your software or binary, even if it may have > >> permissions to do so. > >> > > That's not a specific use case. > Either you should provide a patch or an exemple of a real program that > is limited by the current design of pledge. > > Currently, if you want a program that can only read a file, you pledge > rpath. If you want the ability to exec file, you pledge exec. > > If you want a program that can exec a set of file and write in > another, either you run your program as a user and group that can't > write the set of file you want to exec (W^X) or you write two program, > one pledging for write the other for read. > > There following paper have an exemple of how the second design can be done. > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html > > > -- > > Cordialement, Coues Ludovic > +336 148 743 42
Building OpenBSD 6.0 -stable - Error
installed a fresh 6.0 AMD64 and tried to build 'stable' from source. Here is what I did as 'root' (as described in: http://www.openbsd.org/stable.html): export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs cd /usr; cvs checkout -P -rOPENBSD_6_0 src # cd /usr/src/sys/arch/$(uname -m)/conf # config GENERIC.MP # cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC.MP # make clean && make # cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC.MP # make install # reboot # rm -rf /usr/obj/* # cd /usr/src # make obj and I get following error message: ===> lib ===> lib/csu /usr/src/lib/csu/obj -> /usr/obj/lib/csu ===> lib/libarch ===> lib/libarch/alpha /usr/src/lib/libarch/alpha/obj -> /usr/obj/lib/libarch/alpha ===> lib/libarch/amd64 /usr/src/lib/libarch/amd64/obj -> /usr/obj/lib/libarch/amd64 ===> lib/libarch/arm /usr/src/lib/libarch/arm/obj -> /usr/obj/lib/libarch/arm ===> lib/libarch/i386 /usr/src/lib/libarch/i386/obj -> /usr/obj/lib/libarch/i386 ===> lib/libarch/mips64 /usr/src/lib/libarch/mips64/obj -> /usr/obj/lib/libarch/mips64 ===> lib/libc /usr/src/lib/libc/obj -> /usr/obj/lib/libc ===> lib/libcrypto make: don't know how to make obj Stop in lib/libcrypto *** Error 2 in lib (:48 'obj') *** Error 1 in /usr/src (:48 'obj') Thank you for your support.
Re: Trying to find/install msgfmt(1) from gettext
On 2016-09-02, Nick Gonellawrote: > I'm currently trying to port some code from Linux and within the > Makefile, there is a reference to the utility msgfmt(1). After some > Googling, I found that this should come as a part of gettext(1), but I > can't seem to find how to get msgfmt(1) on OpenBSD. Any advice you have > would be appreciated. Regards, $ pkg_add pkglocatedb .. $ pkg_locate bin/msgfmt gettext-tools-0.19.7p1:devel/gettext-tools:/usr/local/bin/msgfmt mailman-2.1.22:mail/mailman:/usr/local/lib/mailman/bin/msgfmt.py
Re: OpenBSD 6.0 panic
On 2016-09-03, Bastien Durelwrote: > Le 02/09/2016 à 23:28, Ryan Freeman a écrit : >> On Fri, Sep 02, 2016 at 06:25:15PM +0200, Bastien Durel wrote: >>> Hello. >>> >>> I upgraded my router to 6.0 yesterday, and now I got a panic each time >>> I reboot it. >> >> Hi, >> >> Did you happen to forget to do your pkg_add -u to upgrade packages? I >> suspect it might be openvpn not updated yet throwing the error? >> >> Cheers! >> -ryan >> > Hello, > > I did ran pkg_add -u, but there's a mess in my package database, and > some packages was not registered I would do this: run pkg_check, let it finish, run pkg_add -u, run pkg_check again. But I don't think it's related to the panic. > But upgrading it did not solved the panic (I would have been surprised > if an application crash made the kernel panic) It's a bug obviously, but it can happen sometimes.
Re: might it be better to have three paths lists
On 2016-09-03, ludovic coueswrote: > What is the use case ? More than "what is the use case" is needed here - a good start would be a diff for 3 or 4 examples of existing programs in base showing how it would be used to improve things.
Re: System monitor in base?
On 2016-09-02, Martijn van Durenwrote: > On 09/03/16 00:46, Aioi Yuuko wrote: >> Hi, >> >> I'm trying to wean myself off external packages as much as possible. Is >> there a common, accepted way of viewing, for instance, battery life, with >> only included programs? >> > > It depends upon your precise needs, but you could look into sensorsd(8) > and snmpd(8), or just run apm(8) if you want the current status. > > I like "systat sensors" if I'm watching temperatures etc.
Re: might it be better to have three paths lists
2016-09-03 11:04 GMT+02:00 Luke Small: > > > Sorry I was in the middle of something, but pledge can be a broad brush, > unless you are dealing with one file, whether it is executed, read, or > written and giving per process file permissions sounds pretty neat, and it > might just be a little simpler than making new users for each subset of > privileges, populating each chrooted home folder with a specific set of > permissions (as is what appears to me to have happened with pkg_add). Since > pledge's promises can make it where you can execute a file without read > permission, it seems ideal to continue that tradition with the paths > > On Sat, Sep 3, 2016, 03:07 Luke Small wrote: >> >> In pledge, presumably there will be an accessible paths list. Maybe you >> grant a process root access, and you need to read a file which is only >> granted by root access, and you need write access for another file, so the >> pledge permissions reflect that. On the presumed current path, you would >> leave write access for the first file and maybe you don't need the process >> to have read permissions on an execl() program. You can prohibit your >> process from reading your software or binary, even if it may have >> permissions to do so. >> That's not a specific use case. Either you should provide a patch or an exemple of a real program that is limited by the current design of pledge. Currently, if you want a program that can only read a file, you pledge rpath. If you want the ability to exec file, you pledge exec. If you want a program that can exec a set of file and write in another, either you run your program as a user and group that can't write the set of file you want to exec (W^X) or you write two program, one pledging for write the other for read. There following paper have an exemple of how the second design can be done. http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html -- Cordialement, Coues Ludovic +336 148 743 42
Re: System monitor in base?
On Fri, Sep 02, 2016 at 05:02:07PM -0700, Aioi Yuuko wrote: > Sorry, I was vague in my original email: What I meant was, I'm aware that > there are ways of getting it off the command line; I'm mostly curious about > getting it on my desktop so it's easy to glance at. Would my best bet be > running a script like that in a particular xterm, and marking that xterm as > sticky in fvwm?On 2 Sep 2016 16:22, Raf Czlonkawrote: > > $ systat vm Reyk > > On Fri, Sep 02, 2016 at 11:46:27PM BST, Aioi Yuuko wrote: > > > Hi, > > > > > > I'm trying to wean myself off external packages as much as possible. > > > Is there a common, accepted way of viewing, for instance, battery > > > life, with only included programs? > > > > Hi Aioi, > > > > There's the already mentioned apm(8) (i.e. -l, -m options) or you > > could run something like this: > > > > #!/bin/sh > > > > sysctl -n hw.sensors.acpiac0.indicator0 \ > > hw.sensors.acpibat0.watthour0 \ > > hw.sensors.acpibat0.watthour3 | awk 'NR == 1 { ac = $1 } > > NR == 2 { full = $1 } > > NR == 3 { remaining = $1 } > > END { if ( ac == "On" ) > > state = "charging" > > else > > state = "discharging" > > printf("%s %d%s %s%s\n", "Remaining battery life is", > > remaining/full*100, "% and it is", state, "\.") }' > > > > Regards, > > > > Raf > --
Re: might it be better to have three paths lists
In pledge, presumably there will be an accessible paths list. Maybe you grant a process root access, and you need to read a file which is only granted by root access, and you need write access for another file, so the pledge permissions reflect that. On the presumed current path, you would leave write access for the first file and maybe you don't need the process to have read permissions on an execl() program. You can prohibit your process from reading your software or binary, even if it may have permissions to do so. On Sat, Sep 3, 2016, 02:34 ludovic coueswrote: > What is the use case ? > > 2016-09-03 4:15 GMT+02:00 Luke Small : > > wouldn't it be more secure to have a write, read, and execute capable > paths > > lists in pledge() > > > > > > -- > > Cordialement, Coues Ludovic > +336 148 743 42
Re: OpenBSD 6.0 panic
Le 02/09/2016 à 23:28, Ryan Freeman a écrit : On Fri, Sep 02, 2016 at 06:25:15PM +0200, Bastien Durel wrote: Hello. I upgraded my router to 6.0 yesterday, and now I got a panic each time I reboot it. Hi, Did you happen to forget to do your pkg_add -u to upgrade packages? I suspect it might be openvpn not updated yet throwing the error? Cheers! -ryan Hello, I did ran pkg_add -u, but there's a mess in my package database, and some packages was not registered # pkg_add openvpn quirks-2.241 signed on 2016-07-26T16:56:10Z Collision in openvpn-2.3.11: the following files already exist /usr/local/include/openvpn/openvpn-plugin.h from openvpn-2.3.11 (different checksum) /usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.a from openvpn-2.3.11 (different checksum) /usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.la from openvpn-2.3.11 (same checksum) /usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so from openvpn-2.3.11 (different checksum) /usr/local/man/man8/openvpn.8 from openvpn-2.3.11 (different checksum) /usr/local/sbin/openvpn from openvpn-2.3.11 (different checksum) [...] wide-dhcpc6 was affected too. But upgrading it did not solved the panic (I would have been surprised if an application crash made the kernel panic) -- Bastien
Re: might it be better to have three paths lists
What is the use case ? 2016-09-03 4:15 GMT+02:00 Luke Small: > wouldn't it be more secure to have a write, read, and execute capable paths > lists in pledge() > -- Cordialement, Coues Ludovic +336 148 743 42