SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Files containing sensitive data are usually read by a process before privileges are dropped so that the file's contents can't be accessed by a compromised server process running under the non-privileged userid. I'm not familiar with bind/rndc, but it wouldn't surprise me to be told that root:root is the correct choice here given that the file contains a cryptographic key.
Files containing sensitive data are usually read by a process before privileges are dropped so that the file's contents can't be accessed by a compromised server process running under the non-privileged userid. I'm not familiar with bind/rndc, but it wouldn't surprise me to be told that root:root is the correct choice here given that the file contains a cryptographic key.
Me, I don't want anything
This is a fact
If you remove bind and the file /etc/rndc.key
After a new install
the rndc.key installed is :
Code:
-rw------- 1 named named 100 sept. 19 00:05 rndc.key
cf. doinst.sh.gz in my last post
Like I said, I don't use bind
I don't know if it's correct or not
I just give the facts
Anyway, I'm not surprised that a file that has to be read by a service owned by named has this kind of owner and permissions (0600)
bash-5.1$ xz -d wine-6.17.tar.xz
bash-5.1$ tar -xzvf wine-6.17.tar
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
bash-5.1$
also now i test to build wine-6.17, i think is not recommended for Linux, but some users want :
Code:
configure: creating ./config.status
config.status: creating Make.tmp
config.status: creating include/config.h
config.status: linking tools/winewrapper to wine
config.status: linking tools/winewrapper to wine64
config.status: executing include/stamp-h commands
config.status: executing tools/makedep commands
config.status: executing Makefile commands
configure: libhal 64-bit development files not found, no legacy dynamic device support.
configure: OSS sound system found but too old (OSSv4 needed), OSS won't be supported.
configure: libFAudio 64-bit development files not found, XAudio2 won't be supported.
configure: libcapi20 64-bit development files not found, ISDN won't be supported.
configure: libgsm 64-bit development files not found, gsm 06.10 codec won't be supported.
configure: jxrlib 64-bit development files not found, JPEG-XR won't be supported.
configure: vkd3d 64-bit development files not found (or too old), Direct3D 12 won't be supported.
configure: Finished. Do 'make' to compile Wine.
bash-5.1$
Me, I don't want anything
This is a fact
If you remove bind and the file /etc/rndc.key
After a new install
the rndc.key installed is :
Code:
-rw------- 1 named named 100 sept. 19 00:05 rndc.key
cf. doinst.sh.gz in my last post
Like I said, I don't use bind
I don't know if it's correct or not
I just give the facts
Anyway, I'm not surprised that a file that has to be read by a service owned by named has this kind of owner and permissions (0600)
Actually it generates it as root.root
-rw------- 1 root root 77 Sep 19 17:41 rndc.key
You can create it as named user like rndc-confgen -a -u named
-rw------- 1 named root 77 Sep 19 17:41 rndc.key
Those using named as -u named (myself included) will almost always have run it like this, or changed the owner manually, its how its been done for a very many years on most distros
Those using Pats package as option -u named in /etc/default would have been doing this years, those choosing to keep using Pats package and not specifying -u named and running it as root, would not have had to do anything before, just like now.
Patch for ISC BIND to properly start with new rc.bind script:
Code:
--- rc.bind.orig 2021-09-15 15:53:12.000000000 -0400
+++ rc.bind 2021-09-18 05:25:10.902378397 -0400
@@ -46,15 +46,15 @@
chown -R ${BIND_USER}:${BIND_GROUP} /var/named
# Start named:
if [ -x /usr/sbin/named ]; then
- echo "Starting BIND: /usr/sbin/named $NAMED_OPTIONS"
- /usr/sbin/named $NAMED_OPTIONS
+ echo "Starting BIND: /usr/sbin/named $BIND_OPTIONS"
+ /usr/sbin/named $BIND_OPTIONS
sleep 1
fi
# Make sure that named started:
if ! ps axc | grep -q named ; then
echo "WARNING: named did not start."
- echo "Attempting to start named again: /usr/sbin/named $NAMED_OPTIONS"
- /usr/sbin/named $NAMED_OPTIONS
+ echo "Attempting to start named again: /usr/sbin/named $BIND_OPTIONS"
+ /usr/sbin/named $BIND_OPTIONS
sleep 1
if ps axc | grep -q named ; then
echo "SUCCESS: named started."
Otherwise, there is no “-u named” for ISC BIND to start and it fails (see /var/log/syslog).
If there is no -u named it assumes user root and starts up as root just fine, as it requires no -passing of " -u " or whatever
if this does not work for you, i'm sorry, its overcast here today so my ESP cant get through hte clouds to reach your logs, looks like youll have to post an excerpt the old manual way
If there is no -u named it assumes user root and starts up as root just fine, as it requires no -passing of " -u " or whatever
if this does not work for you, i'm sorry, its overcast here today so my ESP cant get through hte clouds to reach your logs, looks like youll have to post an excerpt the old manual way
I don't need ESP to see his point: the script explicitly sets BIND_OPTIONS on line 27, then never uses it. Instead specifying $NAMED_OPTIONS on lines 54 and 61.
The thing I've observed, it would be better if :
rndc.key is own by named:named not by root:root
... made it sound like you were advocating for it.
As I said, the point of dropping privs is to restrict what a daemon can do just in case it is compromised. Having the rndc.key file readable by the userid used for priv-sep seems like a weakness to me.
I have no need for using bind either, but it made me cock an eyebrow so I shared my thoughts.
bash-5.1$ xz -d wine-6.17.tar.xz
bash-5.1$ tar -xzvf wine-6.17.tar
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
bash-5.1$
Err, that’s perfectly expected, you’re asking tar to pass the archive to gzip (-z) to uncompress it, even though you uncompressed it yourself. Of course gzip fails to uncompress something that is no longer compressed…
Besides, even if you didn’t uncompress the archive yourself, you’d need -J instead of -z to ask tar to pass the archive to xz instead of gzip. Or you can simply not use any of the -z, -j, -J options and just let tar figure out which decompressing filter to use, if any.
... made it sound like you were advocating for it.
As I said, the point of dropping privs is to restrict what a daemon can do just in case it is compromised. Having the rndc.key file readable by the userid used for priv-sep seems like a weakness to me.
I have no need for using bind either, but it made me cock an eyebrow so I shared my thoughts.
Yes, I understand.
I didn't really have an opinion on the subject.
I just ran /etc/rc.d/rc.bind and watched what happens in the logs when it failed
I don't need ESP to see his point: the script explicitly sets BIND_OPTIONS on line 27, then never uses it. Instead specifying $NAMED_OPTIONS on lines 54 and 61.
That looks like an obvious mismatch to me.
indeed
probably something like this
Code:
blackstar rc.d # diff -u rc.bind.old rc.bind
--- rc.bind.old 2021-09-19 14:30:42.939299145 +0200
+++ rc.bind 2021-09-19 14:32:10.439199122 +0200
@@ -23,8 +23,8 @@
if [ -z "$BIND_GROUP" ]; then
BIND_GROUP="named"
fi
-if [ -z "$BIND_OPTIONS" ]; then
- BIND_OPTIONS="-u $BIND_USER"
+if [ -z "$NAMED_OPTIONS" ]; then
+ NAMED_OPTIONS="-u $BIND_USER"
fi
# Sanity check. If /usr/sbin/named is missing then it
since /etc/default/named has :
Code:
# Options to run named with:
NAMED_OPTIONS="-u $BIND_USER"
Unicode 14.0 support (David Corbett).
The hb-subset API and the harfbuzz-subset library's ABI are now declared stable.
The harfbuzz-subset library would not have been possible without the work of Garret Rieger and Qunxin Liu from Google Fonts,
and the earlier work of Michiharu Ariza from Adobe.
The hb-style API is now stable and no longer experimental.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.