1

I have a nagios notifcation command that looks like this:

/usr/bin/printf "%b" "NotificationType=$NOTIFICATIONTYPE$\nService=$SERVICEDESC$\nHost=$HOSTALIAS$\nAddress=$HOSTADDRESS$\nState=$SERVICESTATE$\nDateTime=$LONGDATETIME$\nAdditionalInfo=$SERVICEOUTPUT$\n" > $$(mktemp -p $CONTACTADDRESS1$ service.XXXXXXXX.alert)

Adding in some newlines for readability

/usr/bin/printf "%b" 
"NotificationType=$NOTIFICATIONTYPE$\nService=$SERVICEDESC$\nHost=$HOSTALIAS$\nAddress=$HOSTADDRESS$\nState=$SERVICESTATE$\nDateTime=$LONGDATETIME$\nAdditionalInfo=$SERVICEOUTPUT$\n" 
> $$(mktemp -p $CONTACTADDRESS1$ service.XXXXXXXX.alert)

This does actually create a new file in the directory defined by $CONTACTADDRESS1$ which in my case is /home/alert/NagiosAlerts. Only recently delving into permissions and ACLs to this depth I understood that I needed to set the gid and some default ACLs for this folder to ensure that my nagios user was able to write to this directory and that my alert user could read and write to files created here. So I set up the following

# setfacl -Rdm g:nagios:rw /home/alert/NagiosAlerts/
# setfacl -Rm g:nagios:rw /home/alert/NagiosAlerts/

So the folder permissions look like this now

[kanmonitor01]# pwd
/home/alert/NagiosAlerts
[kanmonitor01]# ll ..
total 4
drwxrws---+ 2 alert nagios 4096 Dec 21 14:27 NagiosAlerts
[kanmonitor01]# getfacl .
# file: .
# owner: alert
# group: nagios
# flags: -s-
user::rwx
group::rwx
group:nagios:rw-
mask::rwx
other::---
default:user::rwx
default:group::rw-
default:group:nagios:rw-
default:mask::rw-
default:other::---

So as the nagios user I touch a new file....

[nagios@kanmonitor01]$ whoami
nagios
[nagios@kanmonitor01]$ touch file.bagel
[nagios@kanmonitor01]$ ll file.bagel
-rw-rw----+ 1 nagios nagios 0 Dec 21 14:57 file.bagel

That looks OK to me. The group permission of the file is rw- which I think is the expected outcome. However when the nagios service executes the command at the beginning of the question I end up with this:

[@kanmonitor01]# ll service.iCSThqzg.alert
-rw-------+ 1 nagios nagios 178 Dec 21 14:51 service.iCSThqzg.alert

[kanmonitor01]# getfacl service.iCSThqzg.alert
# file: service.iCSThqzg.alert
# owner: nagios
# group: nagios
user::rw-
group::rw-                      #effective:---
group:nagios:rw-                #effective:---
mask::---
other::---

So it has an ACL just not the one I wanted it to have. This to me is not the expected behavior. I see lots of question about certain binaries not honoring the ACL because of default behavior and such. It looks like my case is that mktemp is somehow causing me this issue. I was trying to avoid some sort of need to do a chmod of every file every time I needed it.

Not sure what a good course of action is here. At the end of the day I need the user nagios to be able to write files to this directory and the user alert to be able to read/write those same files. ACL seem like the way to go.....

  • I suppose at the end of the day I could just resort to something like this ...serverfault.com/a/567024/234050 > getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>. but that would require an existing file to copy which I would not like to keep one hanging around just for that. – Matt Dec 21 '17 at 20:17
1

mktemp explicitly creates the file with permissions 0600

$ strace -e open mktemp -p .
[...]
open("./tmp.EuTEGOcoEJ", O_RDWR|O_CREAT|O_EXCL, 0600) = 3

So that overrides those default ACLs. mktemp does ask group and other not have permissions. A way to deceive it so it doesn't happen would be wrong.

You could chmod the file after creation (go against mktemp's will afterwards):

file=$(mktemp....) && chmod g+r -- "$file" && ... > "$file"

Or use mktemp to find the file's name but not create it, and let the shell redirection create it:

umask 077; ... > "$(mktemp -u ...)"

In that case, the ACL does take precedence over the umask.

The -u (here for GNU mktemp) is for unsafe though as while mktemp will try to come up with a unique file name, it cannot guarantee that the file won't be created (possibly as a symlink to somewhere else which is the kind of thing one might need to worry about here) in between the time it outputs it and the shell opens it. Even set -o clobber cannot safeguard against it as it also has a race condition (you'd need zsh's sysopen -o excl here).

  • Thanks for providing the reason with evidence. These are the kinds of answers I like. – Matt Dec 21 '17 at 21:32
  • This is in line with what I see, when reading your question: Something is doing a g-rwx after the ACL is set. This in setting the mask to ---. – ctrl-alt-delor Dec 21 '17 at 21:35
  • Can't thank you enough for this enlightenment. I can now move on for this project. Thanks for introducing me to strace as well. – Matt Dec 22 '17 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.