Bug 249893 - sysutils/nut -- can't open upsstats.cgi after update nut-2.7.4_14 to nut-2.7.4_16
Summary: sysutils/nut -- can't open upsstats.cgi after update nut-2.7.4_14 to nut-2.7....
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-25 18:42 UTC by AlexG
Modified: 2020-09-27 15:25 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (cy)


Attachments
Revert dvl patch (1.75 KB, patch)
2020-09-26 13:32 UTC, Cy Schubert
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description AlexG 2020-09-25 18:42:40 UTC
Web error:
Error: can't open template file (upsstats.html)

HTTPD error log says:
[Fri Sep 25 11:27:23.117124 2020] [cgi:error] [pid 72959] [client 10.x.x.x:61405] AH01215: upsstats: Can't open /usr/local/etc/nut/upsstats.html: Permission denied: /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi, referer: http://10.x.x.y/nut/header.html

Copy&Past upsstats.html from sample file doesn't help.
Permissions on all folder /usr/local/etc/nut/* is uucp:uucp doesn't help.
Comment 1 Dan Langille freebsd_committer 2020-09-25 20:26:21 UTC
What is ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi ?
Comment 2 Dan Langille freebsd_committer 2020-09-25 20:27:12 UTC
I should have asked: ls -l /usr/local/etc/nut/upsstats.html

But both will do.
Comment 3 Dan Langille freebsd_committer 2020-09-25 20:35:31 UTC
Key to know: apache will be running as www

www needs to read that file.

Why HTML is in /usr/local/etc/ is another issue to resolve later. That should be in /usr/local/www
Comment 4 Cy Schubert freebsd_committer 2020-09-26 04:49:57 UTC
(In reply to Dan Langille from comment #3)

${LOCALBASE}/etc/nut/ is the proper place for it. It is not read by apache/nginx. It's is interpreted by upsstats.c (upsstats.cgi):

slippy$ ag display_template upsstats.c
843:static void display_template(const char *tfn)
1037:		display_template("upsstats-single.html");
1062:	display_template("upsstats.html");
slippy$ 

upsstats.html is a config file, not a raw html file.
Comment 5 Cy Schubert freebsd_committer 2020-09-26 04:59:42 UTC
(In reply to Dan Langille from comment #1)

This isn't all the information we need.

AH01215: upsstats: Can't open /usr/local/etc/nut/upsstats.html: Permission denied: /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi, referer: http://10.x.x.y/nut/header.html

This is telling us that /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi (a binary produced by upsstats.c) cannot read its config file /usr/local/etc/nut/upsstats.html.

Can you ls -l /usr/local/etc/nut/upsstats.html.

What ID is your cgi running under?

While we're at it, the following. I want to verify that upsstats.cgi isn't an invalid format ELF file.

ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi
file /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi.

I suspect that /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi is running under an account that does not have read access to /usr/local/etc/nut/upsstats.html or the directory hierarchy it is in.
Comment 6 AlexG 2020-09-26 08:59:31 UTC
(In reply to Cy Schubert from comment #5)

> Can you ls -l /usr/local/etc/nut/upsstats.html.
-rw-r--r--  1 uucp  uucp  4003 23 авг.  18:32 /usr/local/etc/nut/upsstats.html

> What ID is your cgi running under?
What are you mean? nut process id or something else?

> ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi
-r-xr-xr-x  1 root  wheel  48520 23 авг.  18:32 /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi

> file /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi.
/usr/local/www/apache24/cgi-bin/nut/upsstats.cgi: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.1, FreeBSD-style, stripped
Comment 7 AlexG 2020-09-26 09:11:58 UTC
Just FYI: I want to add... that with the same permissions in the nut-2.7.4_14 version everything works and every time I fixed permissions for whole folder:
chown -R uucp:uucp /usr/local/etc/nut/*
Right after update permissions for changed files (not edited config files) has permissions: root:wheel, that why I fixed permissions but this trick doesn't help at this time.
Comment 8 Cy Schubert freebsd_committer 2020-09-26 13:29:22 UTC
(In reply to AlexG from comment #6)
No, we already know nut is running under the uucp id. What id is the upsstat.cgi running under? Probably apache or an account of your choosing if you configured apache that way. What specific id is upsstat.cgi running under?
Comment 9 Cy Schubert freebsd_committer 2020-09-26 13:32:45 UTC
Created attachment 218325 [details]
Revert dvl patch

Try this.
Comment 10 Dan Langille freebsd_committer 2020-09-26 16:10:22 UTC
(In reply to Cy Schubert from comment #9)
I hope it's not that.  It affects only .sample files.
Comment 11 Cy Schubert freebsd_committer 2020-09-26 16:30:38 UTC
(In reply to Dan Langille from comment #10)
That was the only other change, it couldn't be the syslog.d part of your patch.

Why would the port magically change after two seemingly changes unrelated to this PR?
Comment 12 AlexG 2020-09-26 16:34:55 UTC
(In reply to Cy Schubert from comment #8)
I thing apache used www id this is default account what running all cgi scripts
Comment 13 Dan Langille freebsd_committer 2020-09-26 17:15:28 UTC
OP says:

"Right after update permissions for changed files (not edited config files) has permissions: root:wheel, that why I fixed permissions but this trick doesn't help at this time."

If a trick has always been needed, something was not right before.
Comment 14 Cy Schubert freebsd_committer 2020-09-26 20:44:14 UTC
(In reply to Dan Langille from comment #13)
The difference between your patch and without it is:

With dvl patch the permissions are 0640:

-rw-r-----  1 root  uucp    6.7K Sep 25 22:31 upsstats-single.html
-rw-r-----  1 root  uucp    6.7K Sep 25 22:31 upsstats-single.html.sample
-rw-r-----  1 root  uucp    4.0K Sep 25 22:31 upsstats.html
-rw-r-----  1 root  uucp    4.0K Sep 25 22:31 upsstats.html.sample

Without dvl patch the permissions are 0644:

-rw-r--r--  1 root  wheel   6.7K Sep 26 13:39 upsstats-single.html
-rw-r--r--  1 root  wheel   6.7K Sep 26 13:39 upsstats-single.html.sample
-rw-r--r--  1 root  wheel   4.0K Sep 26 13:39 upsstats.html
-rw-r--r--  1 root  wheel   4.0K Sep 26 13:39 upsstats.html.sample

This is why upsstats.cgi cannot read the file. It's running under the apache account under the control of apache. The permissions are too restrictive. And, the only way this can work is if the files are in the apache group, not uucp, OR if the apache account is also in the uucp group.

I will revert the patch.
Comment 15 commit-hook freebsd_committer 2020-09-26 20:46:31 UTC
A commit references this bug:

Author: cy
Date: Sat Sep 26 20:46:03 UTC 2020
New revision: 550222
URL: https://svnweb.freebsd.org/changeset/ports/550222

Log:
  Revert r549867. The permissions were wrong.

  PR:		249893

Changes:
  head/sysutils/nut/Makefile
  head/sysutils/nut/pkg-plist
  head/sysutils/nut-devel/Makefile
  head/sysutils/nut-devel/pkg-plist
Comment 16 Cy Schubert freebsd_committer 2020-09-26 20:51:56 UTC
Sorry for the breakage. I should have tested the patch more thoroughly before committing it.
Comment 17 Dan Langille freebsd_committer 2020-09-26 20:55:21 UTC
Now I understand.  Sorry.

I still assert that at least some sample files need different permissions to work out of the box.  That's what I found when setting it up for the first time.

I see now why that does not apply to the NUT_CGI but I'm sure it does apply to the ETCDIR files.
Comment 18 Dan Langille freebsd_committer 2020-09-26 20:55:56 UTC
(In reply to Cy Schubert from comment #16)
And I should have tested with NUT_CGI which I am not using. Sorry.
Comment 19 Cy Schubert freebsd_committer 2020-09-26 20:58:31 UTC
(In reply to Dan Langille from comment #18)
I don't use it here either. It's simpler to log into my gateway and issue the command, especially with JuiceSSH from my phone, because I'd never expose anything like that out on the public side of my network.
Comment 20 Cy Schubert freebsd_committer 2020-09-26 21:06:38 UTC
BTW, this and cleaner log entries are the reasons I refactor patches to commit functional patches separately. It's so much easier reverting patches and helps people who want to browse the logs looking for errors like this. It's especially handy in src. Otherwise the commit logs look more like Linux commit logs, making it more difficult to separate out one part of a jumbo patch to resolve bugs.
Comment 21 Dan Langille freebsd_committer 2020-09-26 21:50:46 UTC
(In reply to Cy Schubert from comment #20)

Yes, I like that.
Comment 22 AlexG 2020-09-27 15:25:53 UTC
(In reply to commit-hook from comment #15)
After update to version nut-2.7.4_17 all working as usually.
Thank you very much!