Re: [patch] Add error check for fchmod in ldconfig.c
On Thu, Jun 07, 2018 at 03:31:16PM +0800, Nan Xiao wrote:
> Hi tech@,
>
> Maybe a error check of fchmod is necessary. [...]
In that spot I think the only way fchmod can fail is with EIO.
But, for sake of discussion, suppose it fails with EIO and then all
the subsequent writes succeed and the EIO, for whatever reason, was
spurious or somehow not indicative of deeper instability, and the
system remains up and stable afterward: I think there are then two
problems with proceeding after fchmod fails.
One, installing ld.so.hints when it's writable by root sounds like
a bad idea. I'm not sure it matters in practice as root can open a
read-only file with write privileges anyway, but in principle the hints
file should be read-only for everyone.
Two, installing ld.so.hints when it isn't readable by the rest of the
system sort of defeats the purpose of ld.so.hints: speeding up shared
library lookup for everyone.
Unless this is the very first run of ldconfig, there will be a legible
and useful hints file in-place already... which we'd then overwrite
with one only readable by root processes.
Ideally, most processes are not root processes, so this potentially adds
some overhead for all such processes without LD_LIBRARY_PATH set, which
would not be ideal.
--
This patch is ok cheloha@ and I can commit this if someone else is ok with
it, but I'd really like to hear from someone with more familiarity with
the run-time linking process: is my analysis here off-base?
--
Scott Cheloha
> Index: ldconfig.c
> ===
> RCS file: /cvs/src/libexec/ld.so/ldconfig/ldconfig.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 ldconfig.c
> --- ldconfig.c26 Apr 2018 12:42:50 - 1.37
> +++ ldconfig.c7 Jun 2018 07:04:45 -
> @@ -386,7 +386,11 @@ buildhints(void)
> warn("%s", tmpfilenam);
> goto out;
> }
> - fchmod(fd, 0444);
> +
> + if (fchmod(fd, 0444) == -1) {
> + warn("%s", tmpfilenam);
> + goto out;
> + }
>
> if (write(fd, , sizeof(struct hints_header)) !=
> sizeof(struct hints_header)) {
>
> --
> Best Regards
> Nan Xiao
>
mg(1): add missing cscope function keybind
It seems to me that keymap.c need to change 'rescan' to 'csfuncalled' in
'static PF cCsc[] = { ... }'.
The reason why I have an impression is that doesn't match between cscope.c,
keymap.c and mg.1.
As you can see as below, cscope.c's comment contains 'C-c s l' keybind.
$ cd /src/usr.bin/mg
$ grep -A 3 -B 5 csfuncalled cscope.c
/*
* Find functions called by this function. Bound to C-c s l
*/
/* ARGSUSED */
int
csfuncalled(int f, int n)
{
return (do_cscope(CSCALLEDFUNCS));
}
$
But, keymap.c and mg.1 do not have 'C-c s l' keybind.
$ grep -A 19 'static PF cCsc' keymap.c
static PF cCsc[] = {
cscallerfuncs, /* c */
csdefinition, /* d */
csegrep,/* e */
csfindfile, /* f */
rescan, /* g */
rescan, /* h */
csfindinc, /* i */
rescan, /* j */
rescan, /* k */
rescan, /* l */
rescan, /* m */
csnextmatch,/* n */
rescan, /* o */
csprevmatch,/* p */
rescan, /* q */
rescan, /* r */
cssymbol, /* s */
csfindtext /* t */
};
$ man mg
(snip)
DEFAULT KEY BINDINGS
Normal editing commands are very similar to GNU Emacs. In the following
examples, C-x means Control-x, and M-x means Meta-x, where the Meta key
may be either a special key on the keyboard or the ALT key; otherwise ESC
followed by the key X works as well.
C-SPC set-mark-command
C-a beginning-of-line
C-b backward-char
C-c s c cscope-find-functions-calling-this-function
C-c s d cscope-find-global-definition
C-c s e cscope-find-egrep-pattern
C-c s f cscope-find-this-file
C-c s i cscope-find-files-including-file
C-c s n cscope-next-symbol
C-c s p cscope-prev-symbol
C-c s s cscope-find-this-symbol
C-c s t cscope-find-this-text-string
C-d delete-char
(snip)
$
OK?
Best regards,
Hajime Edakawa
Index: keymap.c
===
RCS file: /cvs/src/usr.bin/mg/keymap.c,v
retrieving revision 1.58
diff -u -p -r1.58 keymap.c
--- keymap.c29 Dec 2015 19:44:32 - 1.58
+++ keymap.c7 Jun 2018 11:31:21 -
@@ -55,7 +55,7 @@ static PF cCsc[] = {
csfindinc, /* i */
rescan, /* j */
rescan, /* k */
- rescan, /* l */
+ csfuncalled,/* l */
rescan, /* m */
csnextmatch,/* n */
rescan, /* o */
Index: mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.106
diff -u -p -r1.106 mg.1
--- mg.111 Dec 2017 07:27:07 - 1.106
+++ mg.17 Jun 2018 11:31:06 -
@@ -134,6 +134,8 @@ cscope-find-egrep-pattern
cscope-find-this-file
.It C-c s i
cscope-find-files-including-file
+.It C-c s l
+cscope-find-called-functions
.It C-c s n
cscope-next-symbol
.It C-c s p
Re: bgpd: stop with the announce confusion
On Thu, Jun 07, 2018 at 12:14:07PM +0200, Claudio Jeker wrote: > > It would be helpful during upgrades if it's possible to write some > > configurations that work the same on both the old and new versions. > > That way the configuration can be changed to a version which will > > still work before you get to the point where you can't simply revert > > to the old config file). I think if the new version would accept > > but ignore "announce all", that would be enough. > > Yes, I can add a dummy "announce *" handler. In general people should be > already able to write filters that work before and after the change. > Happy to add a bit of code to ease the change but it also comes with a > price that users may not adjust their configs because they don't fail to > load. I'd prefer if only "announce all" is allowed as a no-op (but a warning about the directive's deprecation is printed), for "announce self" and "announce default-route" just throw an error and refuse to start the daemon. Kind regards, Job
Re: bgpd: stop with the announce confusion
On Thu, Jun 07, 2018 at 12:14:07PM +0200, Claudio Jeker wrote: > On Thu, Jun 07, 2018 at 10:20:17AM +0100, Stuart Henderson wrote: > > On 2018/06/07 10:26, Claudio Jeker wrote: > > > On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > > > > So the announce keyword in bgpd is massivly overloaded. > > > > It is one of the most common things new bgpd users are unsure about. > > > > These are all possible announce options: > > > > > > > > announce (IPv4|IPv6) (none|unicast|vpn) > > > > announce as-4byte (yes|no) > > > > announce capabilities (yes|no) > > > > announce refresh (yes|no) > > > > announce restart (yes|no) > > > > and > > > > announce (all|none|self|default-route) > > > > > > > > Especially the last one is a bit confusing because it influences the way > > > > the filter work. This was good in the beginning of bgpd but now I think > > > > the time is right to move on. Filtering in general got more important > > > > and > > > > using large-communities as a method to tag prefixes so that they can be > > > > matched against those later is important. > > > > People are easily confused by `announce IPv4 unicast` vs `announce all` > > > > and so on. > > > > > > > > The following diff does a few things. > > > > a) it removes the `announce (all|none|self|default-route)` version > > > > b) `announce none` is now `export none` > > > > c) `announce default-route` is now `export default-route` > > > > d) the examples file is adjusted accordingly and also the network > > > >statements are no setting a large-community which is used by the > > > >filters. > > > > e) the filters are split in input and output and to a lesser extent > > > >ibgp vs ebgp. > > > > f) since anounce self is gone the filters will now default deny (which > > > > is > > > >not a big thing and has the benefit that at start all routes show up > > > > in > > > >Adj-RIB-In first). > > > > > > > > In general people using `announce all` can just remove the line. When > > > > using `annouce self` more care is needed since the filters may need > > > > extra > > > > adjustment. `announce none` and `announce default-route` are simple > > > > renames, every thing else remains the same. > > > > > > > > > > To be more precise what needs to be changed in your config. > > > > > > - neighbors using 'announce none' just rename it to 'export none' > > > - neighbors using 'announce default-route' just rename it to 'export > > > default-route' > > > > > > For all other cases 'announce self' and 'announce all' needs to be removed > > > and filters need to be put in place instead. A good example is in > > > /etc/example/bgpd.conf. In short you want to permit ibgp in and out and > > > for ebgp you want to only allow reasonable things in and only your > > > announcements out. How is this done best is by tagging announcements with > > > a community. I use large-community here because they are more expressive. > > > > > > # tag announcements with a community > > > network 10.0.1.0/24 set large-community $ASN:1:1 > > > > > > ... neighbor configs ... > > > > > > # first inbound > > > allow from ibgp > > > # the example filters out a lot of bad prefixes here which is good > > > # In general you don't trust the outside world so this is where you should > > > # filter the most. > > > allow from ebgp inet prefixlen 8 - 24 > > > allow from ebgp inet6 prefixlen 16 - 48 > > > # scrub our community range from ebgp > > > match from ebgp set large-community delete $ASN:*:* > > > > > > # now outbound filters > > > # again ibgp is generally allowed > > > allow to ibgp > > > # for ebgp make sure to not leak any unintended networks so best is to > > > # just allow the networks we tagged. > > > allow to ebgp large-community $ASN:1:1 > > > # another option is to go eplicit by network > > > allow to ebgp prefix 10.0.1.0/24 > > > > > > For a pure ibgp router the basic rules can be simplified to: > > >allow from ibgp > > >allow to ibgp > > > > > > While most configs probably have inbound filters they may lack outbound > > > filters. It is possible to check the effect of this change by adding > > >deny from any > > >deny to any > > > at the start of your filters. `bgpctl show rib out nei myPeerName` is a > > > great way to see what is announced before and after. > > > > > > See this as an oportunity to bring your bgpd filter up to current > > > standards. > > > -- > > > :wq Claudio > > > > > > > It would be helpful during upgrades if it's possible to write some > > configurations that work the same on both the old and new versions. > > That way the configuration can be changed to a version which will > > still work before you get to the point where you can't simply revert > > to the old config file). I think if the new version would accept > > but ignore "announce all", that would be enough. > > Yes, I can add a dummy "announce *" handler. In general people should be > already able to write filters that work before
Re: bgpd: stop with the announce confusion
On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > The following diff does a few things. > a) it removes the `announce (all|none|self|default-route)` version > b) `announce none` is now `export none` > c) `announce default-route` is now `export default-route` > d) the examples file is adjusted accordingly and also the network >statements are no setting a large-community which is used by the >filters. > e) the filters are split in input and output and to a lesser extent >ibgp vs ebgp. > f) since anounce self is gone the filters will now default deny (which is >not a big thing and has the benefit that at start all routes show up in >Adj-RIB-In first). OK job@ I built a release & tested on a few routers. I like Stuart's suggestion, if the directive "announce all" is made a no-op in 6.4 (and removed in 6.5), I can produce configs that work on both 6.3 and 6.4, making the upgrade easier. Kind regards, Job
Re: bgpd: stop with the announce confusion
On Thu, Jun 07, 2018 at 10:20:17AM +0100, Stuart Henderson wrote: > On 2018/06/07 10:26, Claudio Jeker wrote: > > On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > > > So the announce keyword in bgpd is massivly overloaded. > > > It is one of the most common things new bgpd users are unsure about. > > > These are all possible announce options: > > > > > > announce (IPv4|IPv6) (none|unicast|vpn) > > > announce as-4byte (yes|no) > > > announce capabilities (yes|no) > > > announce refresh (yes|no) > > > announce restart (yes|no) > > > and > > > announce (all|none|self|default-route) > > > > > > Especially the last one is a bit confusing because it influences the way > > > the filter work. This was good in the beginning of bgpd but now I think > > > the time is right to move on. Filtering in general got more important and > > > using large-communities as a method to tag prefixes so that they can be > > > matched against those later is important. > > > People are easily confused by `announce IPv4 unicast` vs `announce all` > > > and so on. > > > > > > The following diff does a few things. > > > a) it removes the `announce (all|none|self|default-route)` version > > > b) `announce none` is now `export none` > > > c) `announce default-route` is now `export default-route` > > > d) the examples file is adjusted accordingly and also the network > > >statements are no setting a large-community which is used by the > > >filters. > > > e) the filters are split in input and output and to a lesser extent > > >ibgp vs ebgp. > > > f) since anounce self is gone the filters will now default deny (which is > > >not a big thing and has the benefit that at start all routes show up in > > >Adj-RIB-In first). > > > > > > In general people using `announce all` can just remove the line. When > > > using `annouce self` more care is needed since the filters may need extra > > > adjustment. `announce none` and `announce default-route` are simple > > > renames, every thing else remains the same. > > > > > > > To be more precise what needs to be changed in your config. > > > > - neighbors using 'announce none' just rename it to 'export none' > > - neighbors using 'announce default-route' just rename it to 'export > > default-route' > > > > For all other cases 'announce self' and 'announce all' needs to be removed > > and filters need to be put in place instead. A good example is in > > /etc/example/bgpd.conf. In short you want to permit ibgp in and out and > > for ebgp you want to only allow reasonable things in and only your > > announcements out. How is this done best is by tagging announcements with > > a community. I use large-community here because they are more expressive. > > > > # tag announcements with a community > > network 10.0.1.0/24 set large-community $ASN:1:1 > > > > ... neighbor configs ... > > > > # first inbound > > allow from ibgp > > # the example filters out a lot of bad prefixes here which is good > > # In general you don't trust the outside world so this is where you should > > # filter the most. > > allow from ebgp inet prefixlen 8 - 24 > > allow from ebgp inet6 prefixlen 16 - 48 > > # scrub our community range from ebgp > > match from ebgp set large-community delete $ASN:*:* > > > > # now outbound filters > > # again ibgp is generally allowed > > allow to ibgp > > # for ebgp make sure to not leak any unintended networks so best is to > > # just allow the networks we tagged. > > allow to ebgp large-community $ASN:1:1 > > # another option is to go eplicit by network > > allow to ebgp prefix 10.0.1.0/24 > > > > For a pure ibgp router the basic rules can be simplified to: > >allow from ibgp > >allow to ibgp > > > > While most configs probably have inbound filters they may lack outbound > > filters. It is possible to check the effect of this change by adding > >deny from any > >deny to any > > at the start of your filters. `bgpctl show rib out nei myPeerName` is a > > great way to see what is announced before and after. > > > > See this as an oportunity to bring your bgpd filter up to current > > standards. > > -- > > :wq Claudio > > > > It would be helpful during upgrades if it's possible to write some > configurations that work the same on both the old and new versions. > That way the configuration can be changed to a version which will > still work before you get to the point where you can't simply revert > to the old config file). I think if the new version would accept > but ignore "announce all", that would be enough. Yes, I can add a dummy "announce *" handler. In general people should be already able to write filters that work before and after the change. Happy to add a bit of code to ease the change but it also comes with a price that users may not adjust their configs because they don't fail to load. > Remember that "announce self" is implicit for ebgp neighbours unless > there's another "announce" keyword, so people might be using
Re: bgpd: stop with the announce confusion
On 2018/06/07 10:26, Claudio Jeker wrote: > On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > > So the announce keyword in bgpd is massivly overloaded. > > It is one of the most common things new bgpd users are unsure about. > > These are all possible announce options: > > > > announce (IPv4|IPv6) (none|unicast|vpn) > > announce as-4byte (yes|no) > > announce capabilities (yes|no) > > announce refresh (yes|no) > > announce restart (yes|no) > > and > > announce (all|none|self|default-route) > > > > Especially the last one is a bit confusing because it influences the way > > the filter work. This was good in the beginning of bgpd but now I think > > the time is right to move on. Filtering in general got more important and > > using large-communities as a method to tag prefixes so that they can be > > matched against those later is important. > > People are easily confused by `announce IPv4 unicast` vs `announce all` > > and so on. > > > > The following diff does a few things. > > a) it removes the `announce (all|none|self|default-route)` version > > b) `announce none` is now `export none` > > c) `announce default-route` is now `export default-route` > > d) the examples file is adjusted accordingly and also the network > >statements are no setting a large-community which is used by the > >filters. > > e) the filters are split in input and output and to a lesser extent > >ibgp vs ebgp. > > f) since anounce self is gone the filters will now default deny (which is > >not a big thing and has the benefit that at start all routes show up in > >Adj-RIB-In first). > > > > In general people using `announce all` can just remove the line. When > > using `annouce self` more care is needed since the filters may need extra > > adjustment. `announce none` and `announce default-route` are simple > > renames, every thing else remains the same. > > > > To be more precise what needs to be changed in your config. > > - neighbors using 'announce none' just rename it to 'export none' > - neighbors using 'announce default-route' just rename it to 'export > default-route' > > For all other cases 'announce self' and 'announce all' needs to be removed > and filters need to be put in place instead. A good example is in > /etc/example/bgpd.conf. In short you want to permit ibgp in and out and > for ebgp you want to only allow reasonable things in and only your > announcements out. How is this done best is by tagging announcements with > a community. I use large-community here because they are more expressive. > > # tag announcements with a community > network 10.0.1.0/24 set large-community $ASN:1:1 > > ... neighbor configs ... > > # first inbound > allow from ibgp > # the example filters out a lot of bad prefixes here which is good > # In general you don't trust the outside world so this is where you should > # filter the most. > allow from ebgp inet prefixlen 8 - 24 > allow from ebgp inet6 prefixlen 16 - 48 > # scrub our community range from ebgp > match from ebgp set large-community delete $ASN:*:* > > # now outbound filters > # again ibgp is generally allowed > allow to ibgp > # for ebgp make sure to not leak any unintended networks so best is to > # just allow the networks we tagged. > allow to ebgp large-community $ASN:1:1 > # another option is to go eplicit by network > allow to ebgp prefix 10.0.1.0/24 > > For a pure ibgp router the basic rules can be simplified to: >allow from ibgp >allow to ibgp > > While most configs probably have inbound filters they may lack outbound > filters. It is possible to check the effect of this change by adding >deny from any >deny to any > at the start of your filters. `bgpctl show rib out nei myPeerName` is a > great way to see what is announced before and after. > > See this as an oportunity to bring your bgpd filter up to current > standards. > -- > :wq Claudio > It would be helpful during upgrades if it's possible to write some configurations that work the same on both the old and new versions. That way the configuration can be changed to a version which will still work before you get to the point where you can't simply revert to the old config file). I think if the new version would accept but ignore "announce all", that would be enough. Remember that "announce self" is implicit for ebgp neighbours unless there's another "announce" keyword, so people might be using it without realising. It would not be very good if those people (who are probably not dealing with BGP often) started redistributing all their transit routes to peers ;)
Re: bgpd: stop with the announce confusion
On Wed, Jun 06, 2018 at 11:04:56PM +0200, Claudio Jeker wrote: > So the announce keyword in bgpd is massivly overloaded. > It is one of the most common things new bgpd users are unsure about. > These are all possible announce options: > > announce (IPv4|IPv6) (none|unicast|vpn) > announce as-4byte (yes|no) > announce capabilities (yes|no) > announce refresh (yes|no) > announce restart (yes|no) > and > announce (all|none|self|default-route) > > Especially the last one is a bit confusing because it influences the way > the filter work. This was good in the beginning of bgpd but now I think > the time is right to move on. Filtering in general got more important and > using large-communities as a method to tag prefixes so that they can be > matched against those later is important. > People are easily confused by `announce IPv4 unicast` vs `announce all` > and so on. > > The following diff does a few things. > a) it removes the `announce (all|none|self|default-route)` version > b) `announce none` is now `export none` > c) `announce default-route` is now `export default-route` > d) the examples file is adjusted accordingly and also the network >statements are no setting a large-community which is used by the >filters. > e) the filters are split in input and output and to a lesser extent >ibgp vs ebgp. > f) since anounce self is gone the filters will now default deny (which is >not a big thing and has the benefit that at start all routes show up in >Adj-RIB-In first). > > In general people using `announce all` can just remove the line. When > using `annouce self` more care is needed since the filters may need extra > adjustment. `announce none` and `announce default-route` are simple > renames, every thing else remains the same. > To be more precise what needs to be changed in your config. - neighbors using 'announce none' just rename it to 'export none' - neighbors using 'announce default-route' just rename it to 'export default-route' For all other cases 'announce self' and 'announce all' needs to be removed and filters need to be put in place instead. A good example is in /etc/example/bgpd.conf. In short you want to permit ibgp in and out and for ebgp you want to only allow reasonable things in and only your announcements out. How is this done best is by tagging announcements with a community. I use large-community here because they are more expressive. # tag announcements with a community network 10.0.1.0/24 set large-community $ASN:1:1 ... neighbor configs ... # first inbound allow from ibgp # the example filters out a lot of bad prefixes here which is good # In general you don't trust the outside world so this is where you should # filter the most. allow from ebgp inet prefixlen 8 - 24 allow from ebgp inet6 prefixlen 16 - 48 # scrub our community range from ebgp match from ebgp set large-community delete $ASN:*:* # now outbound filters # again ibgp is generally allowed allow to ibgp # for ebgp make sure to not leak any unintended networks so best is to # just allow the networks we tagged. allow to ebgp large-community $ASN:1:1 # another option is to go eplicit by network allow to ebgp prefix 10.0.1.0/24 For a pure ibgp router the basic rules can be simplified to: allow from ibgp allow to ibgp While most configs probably have inbound filters they may lack outbound filters. It is possible to check the effect of this change by adding deny from any deny to any at the start of your filters. `bgpctl show rib out nei myPeerName` is a great way to see what is announced before and after. See this as an oportunity to bring your bgpd filter up to current standards. -- :wq Claudio
Re: Should whois(1) and IPv6 default to ANICHOST?
Hi, Any comments? On Sun, May 20, 2018 at 07:48:34PM +0100, Mikolaj Kucharski wrote: > Hi, > > This is very naive patch for whois(1) which makes it work > by default for IPv6 addresses. I went with very minimal > approach here. If string contains colon, it's asumed to > be IPv6 address. Comments welcome. > > Please CC me, as I'm not subscribed to the list. > > Index: whois.c > === > RCS file: /cvs/src/usr.bin/whois/whois.c,v > retrieving revision 1.56 > diff -u -p -u -r1.56 whois.c > --- whois.c 26 Jul 2017 15:48:38 - 1.56 > +++ whois.c 4 Apr 2018 19:01:45 - > @@ -278,7 +278,8 @@ whois(const char *query, const char *ser > * If the TLD is a number, query ARIN, otherwise, use TLD.whois-server.net. > * If the domain does not contain '.', check to see if it is an NSI handle > * (starts with '!') or a CORE handle (COCO-[0-9]+ or COHO-[0-9]+) or an > - * ASN (starts with AS). Fall back to NICHOST for the non-handle case. > + * ASN (starts with AS) or IPv6 address (contains ':'). Fall back to > + * NICHOST for the non-handle and non-IPv6 case. > */ > char * > choose_server(const char *name, const char *country, char **tofree) > @@ -305,6 +306,8 @@ choose_server(const char *name, const ch > else if ((strncasecmp(name, "AS", 2) == 0) && > strtol(name + 2, , 10) > 0 && *ep == '\0') > return (MNICHOST); > + else if (strchr(name, ':') != NULL) /* IPv6 address */ > + return (ANICHOST); > else > return (NICHOST); > } else if (isdigit((unsigned char)*(++qhead))) Regards, Mikolaj
[patch] Use snprintf to implement concat in etc.c
HI tech@, I think maybe one snprintf is more efficient and concise. Sorry if I am wrong, thanks! Index: etc.c === RCS file: /cvs/src/libexec/ld.so/ldconfig/etc.c,v retrieving revision 1.7 diff -u -p -r1.7 etc.c --- etc.c 12 May 2006 23:35:16 - 1.7 +++ etc.c 7 Jun 2018 07:10:30 - @@ -5,6 +5,7 @@ #include #include +#include #include #include #include "ld.h" @@ -61,9 +62,7 @@ concat(const char *s1, const char *s2, c len = strlen(s1) + strlen(s2) + strlen(s3) + 1; str = xmalloc(len); - strlcpy(str, s1, len); - strlcat(str, s2, len); - strlcat(str, s3, len); + snprintf(str, len, "%s%s%s", s1, s2, s3); return (str); } -- Best Regards Nan Xiao
[patch] Add error check for fchmod in ldconfig.c
Hi tech@,
Maybe a error check of fchmod is necessary. Sorry if I am wrong, thanks!
Index: ldconfig.c
===
RCS file: /cvs/src/libexec/ld.so/ldconfig/ldconfig.c,v
retrieving revision 1.37
diff -u -p -r1.37 ldconfig.c
--- ldconfig.c 26 Apr 2018 12:42:50 - 1.37
+++ ldconfig.c 7 Jun 2018 07:04:45 -
@@ -386,7 +386,11 @@ buildhints(void)
warn("%s", tmpfilenam);
goto out;
}
- fchmod(fd, 0444);
+
+ if (fchmod(fd, 0444) == -1) {
+ warn("%s", tmpfilenam);
+ goto out;
+ }
if (write(fd, , sizeof(struct hints_header)) !=
sizeof(struct hints_header)) {
--
Best Regards
Nan Xiao
