Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 04.11.20 um 20:49 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 11:51:12PM +0100, Stefan Esser wrote:

Am 02.11.20 um 23:10 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:

   I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local
   I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.
   If they have some good argument, then we should proceed further.


I would be delighted to be able to install _and use_ two independent
set of packages from the same base system install.  Without recursing
to jails, X forwarding, etc.


I understand the use case, and I agree this may be appropriate for
a development system.

But on a production system I'd never want to have a non-constant and
not generally applied LOCALBASE, at least not on a system that gives
a CLI to unprivileged users. Those could build their own copy of the
LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
unmodified, replacing config files that policies that restrict the
user).

So how this makes attitude to the feature different ?  For me, dev machine
is my production box because what I do is development.  And for user that
need to run an old binary-only 32bit app which requires X libs, for instance,
it also would be a production.


Maybe I'm using the term in a too strict sense, but it has been
consistently used in this way in all the environments I have worked
in during the last few decades:

The term "production server" is generally applied to systems that
are operated by e.g. an admin team (e.g. ITIL operations processes).

You may consider your development work productive ;-), but that does
not make your development system a production system as found e.g.
in a server farm providing internal or public services.

One difference between test vs. production systems is
that development systems are generally operated under less tight
security obligations. You are in full control of the system and
could damage its integrity at will. It does not contain any data
you are not authorized to access.

The opposite is true of most "production systems", which need to
be protected against attacks on confidentiality, integrity, and
availability.


And if LOCALBASE is not compiled into binaries but somehow obtained
at run-time, there are a number of attacks I can imagine (e.g. by
LD_PRELOAD replace the sysctl() call in libc by your own version).

If somebody can LD_PRELOAD their into your process, it makes no sense to talk
about 'security'.


Yes, it takes some effort, but you could e.g. intercept fopen() calls
and manipulate the file name argument.

One of the suggested methods to make programs use a non-default
LOCALBASE was by means of an environment variable, and that makes it
trivial to have programs use an attacker-controlled value compare to
a LD_PRELOAD attack, though. This is acceptable on a development
system, but not on a production system, IMHO.

I'm afraid that sysctl() could be intercepted, if it was used to
determine a run-time value for LOCALBASE, but intercepting fopen()
could accomplish the same result even for hard-coded paths ...


In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
machine.  I am fine with me building both of them in my instance of
poudriere.


This is a use-case for architecture dependent path definitions (which
I have used some 30 years ago on HP-UX which supported 68k and HP-PA
on a single file system that way). Such a feature has been discussed
in FreeBSD multiple times over the decades ...


Ok, let replace /usr/local-i386 by /usr/local-11.4, if you so inclined.


Well, how about /compat/11.4-i386 then?

The HP-UX implementation used e.g. /usr/bin/@hppa/ ... and when a file
name lookup for /usr/bin/somefile did not find it in /usr/bin, it would
try /usr/bin/@ARCH (with ARCH = hppa or 68k, IIRC).

This is not exactly what you asked for, but our Linux emulation might
already contain everything required to allow a 32 bit environment to
exist on a 64 bit system. And by that I mean not the ability to execute
32 bin binaries that we already have, but e.g. to make path lookups by
such binaries consider the compat prefix first.

Ports built in the 32 bit environment should then find all their include
files, libraries ... under the appropriate /compat sub-tree.

That still leaves a few aspects undefined though, e.g. whether config
files in /etc or $LOCALBASE/etc will be different in the "emulation", or
shared with the base system. The same applies to /usr/share, which ought
to be architecture independent.

This could be an alternative layout to e.g. having 32 bit libraries in
/usr/lib32 (with both supported for backwards compatibility).

Regards, STefan


OpenPGP_signature
Description: OpenPGP 

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 04.11.20 um 20:40 schrieb Baptiste Daroussin:

On Wed, Nov 04, 2020 at 11:04:37AM -0800, Rodney W. Grimes wrote:

For 25 years PREFIX has been rigidly a part of the ports infustructure,
why is it that the BASE system has been allowed to de-evolve from this
concept as documented and REQUIRED by:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


I again assert at one time the base system was clean of this,
it has regressed and needs to be fixed.  That fix should restore
the independence of PREFIX.  If 30k ported pieces of software can
do it why can't the base system do it?

Those ports do not require a recompile, why should the base system?


I am just reacting on that phrase, you do really think the ports do not require
a rebuild to be able to relocate from a PREFIX to another? this is a myth!

ports support being built with another prefix than localbase but that is all it
supports.

There has been a flase claim for years that relocating work, but beside the
tools proposing the feature it never worked, or to be fait only on some very
specific port.

But it is just an impossible goal to achieve otherwise as for example all the
path which gets hardcoded at build time depending on the prefix will end up in
the binary looking for resources in a hardcoded prefix at runtime and so fail if
you relocate the package, for example its datadir.


Adding to Baptiste's reply:

While ports have often contained hard-coded dependencies on the PREFIX
used at build time, the changes currently being applied to the base 
system would actually ease having ports that adapt to a different prefix

at run-time.

See Scott Longs proposed getlocalbase() function (D27022), which could
be used by ports to derive at run-time the (currently hard-coded) path
in a standardized way (with fall-back to _PATH_LOCALBASE or /usr/local).

There are potential security issues with a run-time configured PREFIX
though, e.g. if it is used to locate files that contain an admin-
configured policy meant to restrict unprivileged users. Only hard-coded
paths in the respective binaries protect against attacks that manipulate
a dynamic prefix at run-time in such a szenario.

But as long as not all supported versions of FreeBSD support the
getlocalbase() function, it cannot be assumed to be generally available
for use in ports.

And since it will take some time for the currently supported releases to
reach EoL, ports could only conditionally include such a feature when
built on and for a system known to have getlocalbase().

We are in the process of creating the infrastructure that may one day
allow ports to automatically adapt to the PREFIX in use on the system
they are installed on, but we are not there, yet.

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Konstantin Belousov]

On Mon, Nov 02, 2020 at 11:51:12PM +0100, Stefan Esser wrote:
> Am 02.11.20 um 23:10 schrieb Konstantin Belousov:
> > On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
> > >   I think that the first question we want to ask is : Do we want to
> > > support LOCALBASE being different than /usr/local
> > >   I honestly don't see any advantages of making it !=/usr/local/ and
> > > before we start putting a lot of new/useless(for I guess 99% of our
> > > user base) in the tree we should here why people are using /usr/pkg or
> > > whatever weird location.
> > >   If they have some good argument, then we should proceed further.
> > 
> > I would be delighted to be able to install _and use_ two independent
> > set of packages from the same base system install.  Without recursing
> > to jails, X forwarding, etc.
> 
> I understand the use case, and I agree this may be appropriate for
> a development system.
> 
> But on a production system I'd never want to have a non-constant and
> not generally applied LOCALBASE, at least not on a system that gives
> a CLI to unprivileged users. Those could build their own copy of the
> LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
> unmodified, replacing config files that policies that restrict the
> user).
So how this makes attitude to the feature different ?  For me, dev machine
is my production box because what I do is development.  And for user that
need to run an old binary-only 32bit app which requires X libs, for instance,
it also would be a production.

> 
> And if LOCALBASE is not compiled into binaries but somehow obtained
> at run-time, there are a number of attacks I can imagine (e.g. by
> LD_PRELOAD replace the sysctl() call in libc by your own version).
If somebody can LD_PRELOAD their into your process, it makes no sense to talk
about 'security'.

> 
> > In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
> > machine.  I am fine with me building both of them in my instance of
> > poudriere.
> 
> This is a use-case for architecture dependent path definitions (which
> I have used some 30 years ago on HP-UX which supported 68k and HP-PA
> on a single file system that way). Such a feature has been discussed
> in FreeBSD multiple times over the decades ...

Ok, let replace /usr/local-i386 by /usr/local-11.4, if you so inclined.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Baptiste Daroussin]

On Wed, Nov 04, 2020 at 11:04:37AM -0800, Rodney W. Grimes wrote:
> Picking a late message in this thread to reply to
> 
> [ Charset windows-1252 unsupported, converting... ]
> > >>>I think that the first question we want to ask is : Do we want to
> > >>> support LOCALBASE being different than /usr/local
> > >>
> > >> The big majority of users will keep the default value, and I do not
> > >> see a good reason for a change, except if there is a large installed
> > >> base that traditionally uses another prefix (I have seen /vol/local
> > >> and /opt, but also OS and architecture-specific prefixes, for example).
> > > 
> > >   I'd still like to see some arguments for such installs.
> > 
> > There are no reasons, if you have a narrow scope where FreeBSD should
> > get installed. If it only on individual desktop users' system, they
> > are best served with LOCALBASE immutably fixed to /usr/local.
> > 
> > But there are other kinds of user and I have already given examples.
> > Companies that have tooling that traditionally used some other prefix
> > will not rewrite all their tools if we tell them that only /usr/local
> > is supported, for example.
> > 
> > I do not have to justify the existence of such use cases, and I'm happy
> > with /usr/local on all my systems. But I do know that such use cases
> > do exist and I have worked in environments where they were relevant.
> > 
> 
> For 25 years PREFIX has been rigidly a part of the ports infustructure,
> why is it that the BASE system has been allowed to de-evolve from this
> concept as documented and REQUIRED by:
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html
> 
> 
> I again assert at one time the base system was clean of this,
> it has regressed and needs to be fixed.  That fix should restore
> the independence of PREFIX.  If 30k ported pieces of software can
> do it why can't the base system do it?
> 
> Those ports do not require a recompile, why should the base system?

I am just reacting on that phrase, you do really think the ports do not require
a rebuild to be able to relocate from a PREFIX to another? this is a myth!

ports support being built with another prefix than localbase but that is all it
supports.

There has been a flase claim for years that relocating work, but beside the
tools proposing the feature it never worked, or to be fait only on some very
specific port.

But it is just an impossible goal to achieve otherwise as for example all the
path which gets hardcoded at build time depending on the prefix will end up in
the binary looking for resources in a hardcoded prefix at runtime and so fail if
you relocate the package, for example its datadir.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: svn commit: r367280 - head/lib/libc/gen

[Rodney W. Grimes]

Picking a late message in this thread to reply to

[ Charset windows-1252 unsupported, converting... ]
> >>>I think that the first question we want to ask is : Do we want to
> >>> support LOCALBASE being different than /usr/local
> >>
> >> The big majority of users will keep the default value, and I do not
> >> see a good reason for a change, except if there is a large installed
> >> base that traditionally uses another prefix (I have seen /vol/local
> >> and /opt, but also OS and architecture-specific prefixes, for example).
> > 
> >   I'd still like to see some arguments for such installs.
> 
> There are no reasons, if you have a narrow scope where FreeBSD should
> get installed. If it only on individual desktop users' system, they
> are best served with LOCALBASE immutably fixed to /usr/local.
> 
> But there are other kinds of user and I have already given examples.
> Companies that have tooling that traditionally used some other prefix
> will not rewrite all their tools if we tell them that only /usr/local
> is supported, for example.
> 
> I do not have to justify the existence of such use cases, and I'm happy
> with /usr/local on all my systems. But I do know that such use cases
> do exist and I have worked in environments where they were relevant.
> 

For 25 years PREFIX has been rigidly a part of the ports infustructure,
why is it that the BASE system has been allowed to de-evolve from this
concept as documented and REQUIRED by:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html


I again assert at one time the base system was clean of this,
it has regressed and needs to be fixed.  That fix should restore
the independence of PREFIX.  If 30k ported pieces of software can
do it why can't the base system do it?

Those ports do not require a recompile, why should the base system?

> >>>I honestly don't see any advantages of making it !=/usr/local/ and
> >>> before we start putting a lot of new/useless(for I guess 99% of our
> >>> user base) in the tree we should here why people are using /usr/pkg or
> >>> whatever weird location.
> >>
> >> No, why should we [assess] (assuming that word is to be implied in
> >> your sentence) why people want to be able to easily use a different
> >> prefix? That would be a waste of time, IMHO.
> >>
> >> I know that there are legitimate reasons to want a different prefix,
> >> and we had requests to make it easier to support it.
> > 
> >   What are thoses ?
> 
> Please check the mail-lists since I did not save those messages.
> 
> >> We have literal uses of /usr/local in a lot of files in the FreeBSD
> >> base system (more than 1700) and this is not going to change.
> >>
> >> But it was easy to replace a number of such literal pathes in base
> >> system binaries, and we can make it easier for those that need a
> >> different prefix to get it consistently used.
> >>
> >>>If they have some good argument, then we should proceed further.
> >>
> >> You do not have to participate in this effort
> > 
> >   I do have to participate, it's a common project.
> 
> But it does not affect you if you do not use it.
> 
> >   Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
> > there might be some stuff to do there so yes I need to participate.
> 
> Ports should already support PREFIX and LOCALBASE other than /usr/local.
> 
> And the pkg program even supports the LOCALBASE environment variable.
> 
> All we try to do is go away from multiple inconsistent methods and
> mechanisms and make it easier for installations that do have a need
> for a different LOCALBASE to get in consistently applied to all parts
> of the system. (They have to go through the tree and apply local
> patches to program sources or config files, currently, but will then
> have the same result with much more effort spent by each of them.)
> 
> >   And since you never really started a conversation on a ml (that I know
> > of) my only mean to start this participation is answering a commit
> > email.
> 
> There has been a lengthy discussion in the thread about moving the
> calendar data files out of the base system.
> 
> And there is review D26942, which was announced on the -current list
> and which you seem to have missed. Also relevant are D27009, D27014,
> and D27022, which have been mentioned in commits as far they have
> already been committed, but have not been widely announced. You can
> easily
> 
> >> - there are so many
> >> other areas to work on (and I know you are very active in one).
> > 
> >   Only one ? Damn, I should work more then.
> 
> The most recent breakage you caused for me was the backlight kernel
> option that has been introduced without any discussion I'm aware of.
> 
> Yes, I know about your involvement in getting support for modern GPUs
> into FreeBSD and appreciate it.
> 
> >> But please do not ask those that have started to reduce the use of
> >> literal /usr/local in the base system to justify this work.
> > 
> >   

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

   I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local


The big majority of users will keep the default value, and I do not
see a good reason for a change, except if there is a large installed
base that traditionally uses another prefix (I have seen /vol/local
and /opt, but also OS and architecture-specific prefixes, for example).


  I'd still like to see some arguments for such installs.


There are no reasons, if you have a narrow scope where FreeBSD should
get installed. If it only on individual desktop users' system, they
are best served with LOCALBASE immutably fixed to /usr/local.

But there are other kinds of user and I have already given examples.
Companies that have tooling that traditionally used some other prefix
will not rewrite all their tools if we tell them that only /usr/local
is supported, for example.

I do not have to justify the existence of such use cases, and I'm happy
with /usr/local on all my systems. But I do know that such use cases
do exist and I have worked in environments where they were relevant.


   I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.


No, why should we [assess] (assuming that word is to be implied in
your sentence) why people want to be able to easily use a different
prefix? That would be a waste of time, IMHO.

I know that there are legitimate reasons to want a different prefix,
and we had requests to make it easier to support it.


  What are thoses ?


Please check the mail-lists since I did not save those messages.


We have literal uses of /usr/local in a lot of files in the FreeBSD
base system (more than 1700) and this is not going to change.

But it was easy to replace a number of such literal pathes in base
system binaries, and we can make it easier for those that need a
different prefix to get it consistently used.


   If they have some good argument, then we should proceed further.


You do not have to participate in this effort


  I do have to participate, it's a common project.


But it does not affect you if you do not use it.


  Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
there might be some stuff to do there so yes I need to participate.


Ports should already support PREFIX and LOCALBASE other than /usr/local.

And the pkg program even supports the LOCALBASE environment variable.

All we try to do is go away from multiple inconsistent methods and
mechanisms and make it easier for installations that do have a need
for a different LOCALBASE to get in consistently applied to all parts
of the system. (They have to go through the tree and apply local
patches to program sources or config files, currently, but will then
have the same result with much more effort spent by each of them.)


  And since you never really started a conversation on a ml (that I know
of) my only mean to start this participation is answering a commit
email.


There has been a lengthy discussion in the thread about moving the
calendar data files out of the base system.

And there is review D26942, which was announced on the -current list
and which you seem to have missed. Also relevant are D27009, D27014,
and D27022, which have been mentioned in commits as far they have
already been committed, but have not been widely announced. You can
easily


- there are so many
other areas to work on (and I know you are very active in one).


  Only one ? Damn, I should work more then.


The most recent breakage you caused for me was the backlight kernel
option that has been introduced without any discussion I'm aware of.

Yes, I know about your involvement in getting support for modern GPUs
into FreeBSD and appreciate it.


But please do not ask those that have started to reduce the use of
literal /usr/local in the base system to justify this work.


  Seriously ? I have every right to ask you to justify this when it was
not talked about in a public forum.


What is the problem with replacing a literal string with a macro that
provides the exact same string to the compiler (unless its definition
in paths.h is changed).

Why are you against Scott Long suggesting a function getlocalbase()
that can be used as the official method to have a user supplied value
of LOCALBASE become effective in a program instead of local hacks
like checking for the LOCALBASE environment variable in some programs?

This does not affect you at all, since you can continue to hard-code
/usr/local or to continue to fetch LOCALBASE from the environment.

But developers that want to make sure that a non-default value of
LOCALBASE is consistently used by their software can make use of this
function instead of inventing their own.


If you are happy with /usr/local, then you are not affected at all.
And if you need to configure your system to use 

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 23:10 schrieb Konstantin Belousov:

On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:

  I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local
  I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.
  If they have some good argument, then we should proceed further.


I would be delighted to be able to install _and use_ two independent
set of packages from the same base system install.  Without recursing
to jails, X forwarding, etc.


I understand the use case, and I agree this may be appropriate for
a development system.

But on a production system I'd never want to have a non-constant and
not generally applied LOCALBASE, at least not on a system that gives
a CLI to unprivileged users. Those could build their own copy of the
LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
unmodified, replacing config files that policies that restrict the
user).

And if LOCALBASE is not compiled into binaries but somehow obtained
at run-time, there are a number of attacks I can imagine (e.g. by
LD_PRELOAD replace the sysctl() call in libc by your own version).


In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
machine.  I am fine with me building both of them in my instance of
poudriere.


This is a use-case for architecture dependent path definitions (which
I have used some 30 years ago on HP-UX which supported 68k and HP-PA
on a single file system that way). Such a feature has been discussed
in FreeBSD multiple times over the decades ...


But indeed I am not sure if this worth the effort of many people, for many
hours.  If it puts too high burden on everybody, then it is not a good
feature.  Otherwise, it is very convenient in some situations.


Up to now, not much effort has been spent on this issue. I have defined
_PATH_LOCALBASE in paths.h to make it available for the calendar program
to let it lookup port provided data files (and moving those to a port
will simplify the maintenance of these calendar files).

With _PATH_LOCALBASE available, it was sensible to replace literal uses
of /usr/local in the tree with references to this symbolic name (and
thus to easily build a base system for a different LOCALBASE value).

The addition of the user.localbase sysctl tool less than 20 lines of
code in 2 files (sys/kern_mib.c and lib/libc/gen/sysctl.c). This value
can now be used to make /etc/defaults/rc.conf adapt to a changed
LOCALBASE (just a few lines changed).

All in all less than 50 lines of code have been affected, but this
makes it much easier to build a system for a different (fixed)
LOCALBASE.

The getlocalbase() function proposed by Scott Long will allow to use
a user-configured LOCALBASE in programs that use this function instead
of a compiled in path. Another 20 lines of code, not complicated at all.

But the security implications of the use of a dynamic LOCALBASE can be
significant. And thus I do not think that we should put this function
into programs without a prior security assessment. And it would be a
major effort, which IMHO is not justified for most programs.

But this is not an argument against the steps that have been taken up
to now, with little effort and no weakening of security.

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Emmanuel Vadot]

On Tue, 3 Nov 2020 00:32:14 +0200
Konstantin Belousov  wrote:

> On Mon, Nov 02, 2020 at 11:22:15PM +0100, Emmanuel Vadot wrote:
> > On Tue, 3 Nov 2020 00:10:39 +0200
> > Konstantin Belousov  wrote:
> > 
> > > On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
> > > >  I think that the first question we want to ask is : Do we want to
> > > > support LOCALBASE being different than /usr/local
> > > >  I honestly don't see any advantages of making it !=/usr/local/ and
> > > > before we start putting a lot of new/useless(for I guess 99% of our
> > > > user base) in the tree we should here why people are using /usr/pkg or
> > > > whatever weird location.
> > > >  If they have some good argument, then we should proceed further.
> > > 
> > > I would be delighted to be able to install _and use_ two independent
> > > set of packages from the same base system install.  Without recursing
> > > to jails, X forwarding, etc.
> > > 
> > > In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
> > > machine.  I am fine with me building both of them in my instance of
> > > poudriere.
> > > 
> > > But indeed I am not sure if this worth the effort of many people, for many
> > > hours.  If it puts too high burden on everybody, then it is not a good
> > > feature.  Otherwise, it is very convenient in some situations.
> > 
> >  I understand this situation but I think that the best way for you do
> > do that is to use pkg install -r /path/to/my/i386/packages
> > 
> >  Since you will need to tweak you PATH variable to start applications
> > installed in /usr/local-i386 anyway it's not too much to tweak that to
> > the pkg path for your i386 repo.
> > 
> >  The "downside" of using this method is that you will have
> > a /usr/local/ under the /path/to/my/i386/packages.
> >  The "upside" of using this method is that you would be able to use the
> > same i386 packages on a native i386 install and they would install
> > in /usr/local/ (so no tweaking here).
> If I can already use them from non-/usr/local prefix, then it is great
> news (for me).  But I have a reason to doubt.

 If you pkg -r packages you can use a lot of them.

> For instance, a lot of applications are configured at build time to look
> for /usr/local.  Like, gcc with /usr/local/lib/gcc/, and binutils,
> which are actually one of the main use case for me.  So I believe that
> pkg install -r requires chroot/jail for the result to work.

 Yes there is still some cases like that, or packages having
post-install script that don't handle -r.
 We've been working on that with bapt@ for a few months now and still
do. The main motivation of rewriting everything in lua is to be able to
do that but there is still a lot do to.
 Never the less we would appriciate some reports of people using
packages installed with -r.

-- 
Emmanuel Vadot 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Emmanuel Vadot]

On Mon, 2 Nov 2020 23:24:34 +0100
Stefan Esser  wrote:

> Am 02.11.20 um 22:49 schrieb Emmanuel Vadot:
> > On Mon, 2 Nov 2020 22:41:38 +0100
> > Stefan Esser  wrote:
> > 
> >> Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2,
> >> 2020, Stefan Eßer  >>> > wrote:
> >>>
> >>>  Author: se
> >>>  Date: Mon Nov  2 18:48:06 2020
> >>>  New Revision: 367280
> >>>  URL: https://svnweb.freebsd.org/changeset/base/367280
> >>>  
> >>>
> >>>  Log:
> >>>     Re-arrange some of the code to separate writable user tree
> >>>  variables from
> >>>     R/O variables.
> >>>
> >>>     While here fix some nearby style. No functional change intended.
> >>>
> >>>     MFC after:    1 month
> >>>
> >>>
> >>> Is there any phabricator reference for this / these commit(s) + reviewer
> >>> lists?
> >>
> >> The previous commit that has been refined in this one has been
> >> discussed in D27009.
> >>
> >> I had added the new R/W sysctl variable to a switch statement that
> >> contained one R/O string value, and excluded the OID from causing
> >> an error return when a new value had been passed.
> >>
> >> This was functionally OK, but I have decided to move handling of
> >> the new writable variable to before the check for a write attempt
> >> and thus need to test specifically for its OID.
> >>
> >> This sysctl variable is referenced in Scott Longs proposed
> >> getlocalbase() function (D27022), but also in the change to make
> >> it define defaults paths in /etc/defaults/rc.conf (D27014).
> >>
> >> I do not support to make LOCALBASE dynamic for a broad range of
> >> programs, since this could lead to severe security issues (e.g.
> >> when a program is restricted by policy settings LOCALBASE/etc and
> >> an user-defined LOCALBASE could be used to circumvent them.
> >>
> >> There are already programs that respect a LOCALBASE environment
> >> variable, e.g. the pkg program, to allow it to e.g. operate with
> >> a DESTDIR prefix other than "/". This is a program that could
> >> instead use getlocalbase(), IMHO.
> >>
> >> But for security reasons all files that determine policies and
> >> exist in LOCALBASE since they are not distributed as part of the
> >> base system, should be located in a secure way, and that is by
> >> referring to a compiled in trusted path, IMHO.
> >>
> >> Even if the sysctl variable "user.localbase" can only be written to
> >> by root, the use of getlocalbase() provided by a shared library could
> >> allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
> >> leadsto a user provided policy file instead of the admin controlled
> >> one).
> >>
> >> Regards, STefan
> > 
> >   I think that the first question we want to ask is : Do we want to
> > support LOCALBASE being different than /usr/local
> 
> The big majority of users will keep the default value, and I do not
> see a good reason for a change, except if there is a large installed
> base that traditionally uses another prefix (I have seen /vol/local
> and /opt, but also OS and architecture-specific prefixes, for example).

 I'd still like to see some arguments for such installs.

> >   I honestly don't see any advantages of making it !=/usr/local/ and
> > before we start putting a lot of new/useless(for I guess 99% of our
> > user base) in the tree we should here why people are using /usr/pkg or
> > whatever weird location.
> 
> No, why should we [assess] (assuming that word is to be implied in
> your sentence) why people want to be able to easily use a different
> prefix? That would be a waste of time, IMHO.
> 
> I know that there are legitimate reasons to want a different prefix,
> and we had requests to make it easier to support it.

 What are thoses ?

> We have literal uses of /usr/local in a lot of files in the FreeBSD
> base system (more than 1700) and this is not going to change.
> 
> But it was easy to replace a number of such literal pathes in base
> system binaries, and we can make it easier for those that need a
> different prefix to get it consistently used.
> 
> >   If they have some good argument, then we should proceed further.
> 
> You do not have to participate in this effort 

 I do have to participate, it's a common project.
 Also since I also participate in pkg(8) and in ports/Mk lua/blah stuff
there might be some stuff to do there so yes I need to participate.
 And since you never really started a conversation on a ml (that I know
of) my only mean to start this participation is answering a commit
email.

> - there are so many
> other areas to work on (and I know you are very active in one).

 Only one ? Damn, I should work more then.

> But please do not ask those that have started to reduce the use of
> literal /usr/local in the base system to justify this work.

 Seriously ? I have every right to ask you to justify this when it was
not talked about in a public forum.

> If you are happy with 

Re: svn commit: r367280 - head/lib/libc/gen

[Konstantin Belousov]

On Mon, Nov 02, 2020 at 11:22:15PM +0100, Emmanuel Vadot wrote:
> On Tue, 3 Nov 2020 00:10:39 +0200
> Konstantin Belousov  wrote:
> 
> > On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
> > >  I think that the first question we want to ask is : Do we want to
> > > support LOCALBASE being different than /usr/local
> > >  I honestly don't see any advantages of making it !=/usr/local/ and
> > > before we start putting a lot of new/useless(for I guess 99% of our
> > > user base) in the tree we should here why people are using /usr/pkg or
> > > whatever weird location.
> > >  If they have some good argument, then we should proceed further.
> > 
> > I would be delighted to be able to install _and use_ two independent
> > set of packages from the same base system install.  Without recursing
> > to jails, X forwarding, etc.
> > 
> > In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
> > machine.  I am fine with me building both of them in my instance of
> > poudriere.
> > 
> > But indeed I am not sure if this worth the effort of many people, for many
> > hours.  If it puts too high burden on everybody, then it is not a good
> > feature.  Otherwise, it is very convenient in some situations.
> 
>  I understand this situation but I think that the best way for you do
> do that is to use pkg install -r /path/to/my/i386/packages
> 
>  Since you will need to tweak you PATH variable to start applications
> installed in /usr/local-i386 anyway it's not too much to tweak that to
> the pkg path for your i386 repo.
> 
>  The "downside" of using this method is that you will have
> a /usr/local/ under the /path/to/my/i386/packages.
>  The "upside" of using this method is that you would be able to use the
> same i386 packages on a native i386 install and they would install
> in /usr/local/ (so no tweaking here).
If I can already use them from non-/usr/local prefix, then it is great
news (for me).  But I have a reason to doubt.

For instance, a lot of applications are configured at build time to look
for /usr/local.  Like, gcc with /usr/local/lib/gcc/, and binutils,
which are actually one of the main use case for me.  So I believe that
pkg install -r requires chroot/jail for the result to work.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 22:49 schrieb Emmanuel Vadot:

On Mon, 2 Nov 2020 22:41:38 +0100
Stefan Esser  wrote:


Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2,
2020, Stefan Eßer 
> wrote:

 Author: se
 Date: Mon Nov  2 18:48:06 2020
 New Revision: 367280
 URL: https://svnweb.freebsd.org/changeset/base/367280
 

 Log:
    Re-arrange some of the code to separate writable user tree
 variables from
    R/O variables.

    While here fix some nearby style. No functional change intended.

    MFC after:    1 month


Is there any phabricator reference for this / these commit(s) + reviewer
lists?


The previous commit that has been refined in this one has been
discussed in D27009.

I had added the new R/W sysctl variable to a switch statement that
contained one R/O string value, and excluded the OID from causing
an error return when a new value had been passed.

This was functionally OK, but I have decided to move handling of
the new writable variable to before the check for a write attempt
and thus need to test specifically for its OID.

This sysctl variable is referenced in Scott Longs proposed
getlocalbase() function (D27022), but also in the change to make
it define defaults paths in /etc/defaults/rc.conf (D27014).

I do not support to make LOCALBASE dynamic for a broad range of
programs, since this could lead to severe security issues (e.g.
when a program is restricted by policy settings LOCALBASE/etc and
an user-defined LOCALBASE could be used to circumvent them.

There are already programs that respect a LOCALBASE environment
variable, e.g. the pkg program, to allow it to e.g. operate with
a DESTDIR prefix other than "/". This is a program that could
instead use getlocalbase(), IMHO.

But for security reasons all files that determine policies and
exist in LOCALBASE since they are not distributed as part of the
base system, should be located in a secure way, and that is by
referring to a compiled in trusted path, IMHO.

Even if the sysctl variable "user.localbase" can only be written to
by root, the use of getlocalbase() provided by a shared library could
allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
leadsto a user provided policy file instead of the admin controlled
one).

Regards, STefan


  I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local


The big majority of users will keep the default value, and I do not
see a good reason for a change, except if there is a large installed
base that traditionally uses another prefix (I have seen /vol/local
and /opt, but also OS and architecture-specific prefixes, for example).


  I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.


No, why should we [assess] (assuming that word is to be implied in
your sentence) why people want to be able to easily use a different
prefix? That would be a waste of time, IMHO.

I know that there are legitimate reasons to want a different prefix,
and we had requests to make it easier to support it.

We have literal uses of /usr/local in a lot of files in the FreeBSD
base system (more than 1700) and this is not going to change.

But it was easy to replace a number of such literal pathes in base
system binaries, and we can make it easier for those that need a
different prefix to get it consistently used.


  If they have some good argument, then we should proceed further.


You do not have to participate in this effort - there are so many
other areas to work on (and I know you are very active in one).

But please do not ask those that have started to reduce the use of
literal /usr/local in the base system to justify this work.

If you are happy with /usr/local, then you are not affected at all.
And if you need to configure your system to use a different prefix,
you are welcome to let us know which steps are still causing much
effort and should be worked on to make it easier ...

Do you have any reason to be against removal of literal /usr/local
from the base system in favor of using a symbolic name for it?

Regards, STefan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Emmanuel Vadot]

On Tue, 3 Nov 2020 00:10:39 +0200
Konstantin Belousov  wrote:

> On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
> >  I think that the first question we want to ask is : Do we want to
> > support LOCALBASE being different than /usr/local
> >  I honestly don't see any advantages of making it !=/usr/local/ and
> > before we start putting a lot of new/useless(for I guess 99% of our
> > user base) in the tree we should here why people are using /usr/pkg or
> > whatever weird location.
> >  If they have some good argument, then we should proceed further.
> 
> I would be delighted to be able to install _and use_ two independent
> set of packages from the same base system install.  Without recursing
> to jails, X forwarding, etc.
> 
> In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
> machine.  I am fine with me building both of them in my instance of
> poudriere.
> 
> But indeed I am not sure if this worth the effort of many people, for many
> hours.  If it puts too high burden on everybody, then it is not a good
> feature.  Otherwise, it is very convenient in some situations.

 I understand this situation but I think that the best way for you do
do that is to use pkg install -r /path/to/my/i386/packages

 Since you will need to tweak you PATH variable to start applications
installed in /usr/local-i386 anyway it's not too much to tweak that to
the pkg path for your i386 repo.

 The "downside" of using this method is that you will have
a /usr/local/ under the /path/to/my/i386/packages.
 The "upside" of using this method is that you would be able to use the
same i386 packages on a native i386 install and they would install
in /usr/local/ (so no tweaking here).

-- 
Emmanuel Vadot 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Konstantin Belousov]

On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
>  I think that the first question we want to ask is : Do we want to
> support LOCALBASE being different than /usr/local
>  I honestly don't see any advantages of making it !=/usr/local/ and
> before we start putting a lot of new/useless(for I guess 99% of our
> user base) in the tree we should here why people are using /usr/pkg or
> whatever weird location.
>  If they have some good argument, then we should proceed further.

I would be delighted to be able to install _and use_ two independent
set of packages from the same base system install.  Without recursing
to jails, X forwarding, etc.

In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
machine.  I am fine with me building both of them in my instance of
poudriere.

But indeed I am not sure if this worth the effort of many people, for many
hours.  If it puts too high burden on everybody, then it is not a good
feature.  Otherwise, it is very convenient in some situations.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Emmanuel Vadot]

On Mon, 2 Nov 2020 22:41:38 +0100
Stefan Esser  wrote:

> Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2, 
> 2020, Stefan Eßer  > > wrote:
> > 
> > Author: se
> > Date: Mon Nov  2 18:48:06 2020
> > New Revision: 367280
> > URL: https://svnweb.freebsd.org/changeset/base/367280
> > 
> > 
> > Log:
> >    Re-arrange some of the code to separate writable user tree
> > variables from
> >    R/O variables.
> > 
> >    While here fix some nearby style. No functional change intended.
> > 
> >    MFC after:    1 month
> > 
> > 
> > Is there any phabricator reference for this / these commit(s) + reviewer 
> > lists?
> 
> The previous commit that has been refined in this one has been
> discussed in D27009.
> 
> I had added the new R/W sysctl variable to a switch statement that
> contained one R/O string value, and excluded the OID from causing
> an error return when a new value had been passed.
> 
> This was functionally OK, but I have decided to move handling of
> the new writable variable to before the check for a write attempt
> and thus need to test specifically for its OID.
> 
> This sysctl variable is referenced in Scott Longs proposed
> getlocalbase() function (D27022), but also in the change to make
> it define defaults paths in /etc/defaults/rc.conf (D27014).
> 
> I do not support to make LOCALBASE dynamic for a broad range of
> programs, since this could lead to severe security issues (e.g.
> when a program is restricted by policy settings LOCALBASE/etc and
> an user-defined LOCALBASE could be used to circumvent them.
> 
> There are already programs that respect a LOCALBASE environment
> variable, e.g. the pkg program, to allow it to e.g. operate with
> a DESTDIR prefix other than "/". This is a program that could
> instead use getlocalbase(), IMHO.
> 
> But for security reasons all files that determine policies and
> exist in LOCALBASE since they are not distributed as part of the
> base system, should be located in a secure way, and that is by
> referring to a compiled in trusted path, IMHO.
> 
> Even if the sysctl variable "user.localbase" can only be written to
> by root, the use of getlocalbase() provided by a shared library could
> allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
> leadsto a user provided policy file instead of the admin controlled
> one).
> 
> Regards, STefan

 I think that the first question we want to ask is : Do we want to
support LOCALBASE being different than /usr/local
 I honestly don't see any advantages of making it !=/usr/local/ and
before we start putting a lot of new/useless(for I guess 99% of our
user base) in the tree we should here why people are using /usr/pkg or
whatever weird location.
 If they have some good argument, then we should proceed further.

-- 
Emmanuel Vadot 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 02.11.20 um 20:20 schrieb Oliver Pinter:> On Monday, November 2, 
2020, Stefan Eßer 
> wrote:

Author: se
Date: Mon Nov  2 18:48:06 2020
New Revision: 367280
URL: https://svnweb.freebsd.org/changeset/base/367280


Log:
   Re-arrange some of the code to separate writable user tree
variables from
   R/O variables.

   While here fix some nearby style. No functional change intended.

   MFC after:    1 month


Is there any phabricator reference for this / these commit(s) + reviewer 
lists?


The previous commit that has been refined in this one has been
discussed in D27009.

I had added the new R/W sysctl variable to a switch statement that
contained one R/O string value, and excluded the OID from causing
an error return when a new value had been passed.

This was functionally OK, but I have decided to move handling of
the new writable variable to before the check for a write attempt
and thus need to test specifically for its OID.

This sysctl variable is referenced in Scott Longs proposed
getlocalbase() function (D27022), but also in the change to make
it define defaults paths in /etc/defaults/rc.conf (D27014).

I do not support to make LOCALBASE dynamic for a broad range of
programs, since this could lead to severe security issues (e.g.
when a program is restricted by policy settings LOCALBASE/etc and
an user-defined LOCALBASE could be used to circumvent them.

There are already programs that respect a LOCALBASE environment
variable, e.g. the pkg program, to allow it to e.g. operate with
a DESTDIR prefix other than "/". This is a program that could
instead use getlocalbase(), IMHO.

But for security reasons all files that determine policies and
exist in LOCALBASE since they are not distributed as part of the
base system, should be located in a secure way, and that is by
referring to a compiled in trusted path, IMHO.

Even if the sysctl variable "user.localbase" can only be written to
by root, the use of getlocalbase() provided by a shared library could
allow to perform a LD_PRELOAD attack (provide a getlocalbase() that
leadsto a user provided policy file instead of the admin controlled
one).

Regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: svn commit: r367280 - head/lib/libc/gen

[Oliver Pinter]

On Monday, November 2, 2020, Stefan Eßer  wrote:

> Author: se
> Date: Mon Nov  2 18:48:06 2020
> New Revision: 367280
> URL: https://svnweb.freebsd.org/changeset/base/367280
>
> Log:
>   Re-arrange some of the code to separate writable user tree variables from
>   R/O variables.
>
>   While here fix some nearby style. No functional change intended.
>
>   MFC after:1 month


Is there any phabricator reference for this / these commit(s) + reviewer
lists?


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