pledging a portable program

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

pledging a portable program

jordon-7
What is the “official" way to pledge(2) a portable program?

Put #ifdef __OpenBSD__ around the pledge call?

Make an #ifndef __OpenBSD__ block that defined the function to always return
0?

Something better?

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

Jeremie Courreges-Anglas-2
Jordon <[hidden email]> writes:

> What is the “official" way to pledge(2) a portable program?
>
> Put #ifdef __OpenBSD__ around the pledge call?
>
> Make an #ifndef __OpenBSD__ block that defined the function to always
return
> 0?

This kind of tests harm portability in the long run.

> Something better?

How about: detect whether pledge(2) is available.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

Bryan Steele-2
In reply to this post by jordon-7
On Mon, Jan 16, 2017 at 01:05:36PM -0600, Jordon wrote:
> What is the ???official" way to pledge(2) a portable program?
>
> Put #ifdef __OpenBSD__ around the pledge call?
>
> Make an #ifndef __OpenBSD__ block that defined the function to always return
> 0?
>
> Something better?

pledge() itself serves as good annotation of the subsets of POSIX
used by a program, one option to avoid the #ifdef pollution is to
detect if it's available first, otherwise:

        CPPFLAGS="$CPPFLAGS -D\"pledge(promises,paths)=0\""

Or similarly, in some header:

        #define pledge(promises,paths) 0

-Bryan.

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

Darren Tucker
In reply to this post by jordon-7
On Tue, Jan 17, 2017 at 6:05 AM, Jordon <[hidden email]> wrote:
> What is the “official" way to pledge(2) a portable program?

OpenSSH Portable checks for the presence of pledge in configure
(https://anongit.mindrot.org/openssh.git/tree/configure.ac#n1715) and
if not found defines a no-op pledge function
(https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-misc.c#n282)

The advantage of doing it this way is that the mainline code is
unchanged and so does not add additional maintenance burden (ie merge
conflicts).  It also provides a hook for alternative implementation
mechanisms although there are no drop-in replacements at the moment.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

jordon-7
> On Jan 16, 2017, at 4:31 PM, Darren Tucker <[hidden email]> wrote:
>
> On Tue, Jan 17, 2017 at 6:05 AM, Jordon <[hidden email]> wrote:
>> What is the “official" way to pledge(2) a portable program?
>
> OpenSSH Portable checks for the presence of pledge in configure
> (https://anongit.mindrot.org/openssh.git/tree/configure.ac#n1715) and
> if not found defines a no-op pledge function
>
(https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-misc.c#n282)

>
> The advantage of doing it this way is that the mainline code is
> unchanged and so does not add additional maintenance burden (ie merge
> conflicts).  It also provides a hook for alternative implementation
> mechanisms although there are no drop-in replacements at the moment.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>    Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>

Thank you all for the replies.  I like this approach.  I guess it means I will
finally have to learn how that pre-build config thing works!  :)

Jordon

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

jordon-7
In reply to this post by Darren Tucker
> OpenSSH Portable checks for the presence of pledge in configure
> (https://anongit.mindrot.org/openssh.git/tree/configure.ac#n1715) and
> if not found defines a no-op pledge function
>
(https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-misc.c#n282)

I finally took some time to look into this again.

Dumb questions: what is that configure.ac file?  Is that GNU autoconf or some
other config tool?  Was it written by hand or generated?  I need to learn
about the config process and I’m not sure where to start.  I think some of
these build tools have GNU versions and BSD versions (like make).  What is the
BSD standard for config scripts?

*sigh* this is a part of the build process that I have just put off for far
too long…

Reply | Threaded
Open this post in threaded view
|

Re: pledging a portable program

Ingo Schwarze
Hi,

Jordon wrote on Fri, Jan 20, 2017 at 11:01:25PM -0600:

> I need to learn about the config process
> and I'm not sure where to start.

If you want to learn about automatic build configuration,
i'd recommend to *NOT* look at the GNU autotools - and at none
of the other monster systems like cmake, imake etc. either.
Because there, you spend huge amounts of time learning about the
ridiculous overengineering of these tools, and you will likely
not get a reasonable big picture of what the essential tasks
really are.

> What is the BSD standard for config scripts?

I'm not aware of any.  Maybe having one might be nice - but the
need is not very pressing because it's quite simple to write
working autoconfiguration completely from scratch without any
tools.

For example, look at portable mandoc:

  http://mdocml.bsd.lv/cgi-bin/cvsweb/?cvsroot=mdocml

That's an about 30.000 lines codebase of ISO C, but using some
BSD-specific extensions - err(3), fts(3) - and even OpenBSD-specific
extensions - ohash_init(3), reallocarray(3), strlcat(3), strlcpy(3),
strtonum(3) - along with a number of POSIX functions that some older
systems lack.

The configure-script is 474 lines of hand-written POSIX sh(1) code,
human-readable.  It comes with 28 short test*.c files written in
human-readable C and with 17 compat_*.c files that are used to plug
in replacement implementations for functions missing in the system
we want to run on.  Regarding how to use it, see the INSTALL file,
but basically, it boils down to the usual

  ./configure && make && make install

It works on any reasonable system (i didn't test it on systems
that were already obsolete 20 years ago, but is that relevant?)
In particular, it is tested on

 - OpenBSD
 - FreeBSD 9, 10, 11
 - NetBSD
 - DragonFly BSD
 - illumos
 - Minix 3
 - Alpine, Arch, Slackware, Crux Linux
 - Void Linux with both glibc and musl
 - debian GNU/Linux wheezy, jessie, stretch, sid
 - CentOS 5 & 6, Fedora 20, RHEL 5 & 6
 - SLES 11, openSUSE 13, xUbuntu 12 & 14
 - MacOS X Tiger and El Capitan
 - IBM AIX 7.1
 - Oracle Solaris 11
 - SUN OS 5.9 and 5.10

Do you want to support more?  Like, what about 4.3BSD-Reno?
Or maybe DEC ULTRIX?  Not really, right?

Yours,
  Ingo