Bug 220201 - mail/dcc-dccd: Permission incorrectly changed after update to 1.3.159
Summary: mail/dcc-dccd: Permission incorrectly changed after update to 1.3.159
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Richard Gallamore
Depends on:
Reported: 2017-06-22 03:31 UTC by Richard Gallamore
Modified: 2017-07-03 17:39 UTC (History)
3 users (show)

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

patch (2.11 KB, patch)
2017-06-24 10:15 UTC, Piotr Kubaj
pkubaj: maintainer-approval+
Details | Diff
patch (2.32 KB, patch)
2017-06-27 07:20 UTC, Piotr Kubaj
pkubaj: maintainer-approval+
Details | Diff
patch (2.85 KB, patch)
2017-06-29 13:05 UTC, Piotr Kubaj
no flags Details | Diff
dcc-dccd.diff (3.35 KB, patch)
2017-07-02 21:12 UTC, Richard Gallamore
pkubaj: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Gallamore freebsd_committer 2017-06-22 03:31:37 UTC
After updating dcc-dccd from version 1.3.158 to 1.3.159 I get the following error in maillog:

Jun 20 08:49:46 mx dccproc[25482]: open(/usr/local/dcc/map): Permission denied

% ls -l /usr/local/dcc/map
-rw-------  1 dcc  wheel  7700 Jun 20 08:51 /usr/local/dcc/map

% ls -l /usr/local/dcc/map
-rw-------  1 root  wheel  7700 Jun 20 08:53 /usr/local/dcc/map

Other files with different owner:

Comment 1 Piotr Kubaj freebsd_committer 2017-06-24 08:46:52 UTC
It seems to be an upstream error. I don't use DCC as a daemon, so I haven't noticed. Patch will follow shortly with $CHOWN's in Makefile, which will hopefully restore the previous behavior.
Comment 2 Piotr Kubaj freebsd_committer 2017-06-24 10:15:37 UTC
Created attachment 183759 [details]

It seems like ownership set in Makefile is properly set in the relevant files in $STAGEDIR, but pkg-install.in sets them again to root:wheel. The patch sets ownsership in pkg-install. Could you try the port now?

In maillog, I now get:
Jun 24 12:14:56 FreeBSD10 dccifd[84602]: 1.3.159 listening to /usr/local/dcc/dccifd for ASCII protocol
Comment 3 Richard Gallamore freebsd_committer 2017-06-24 18:38:47 UTC
(In reply to Piotr Kubaj from comment #2)
 I'm glad you responded with a solution! I have been spending a bit too much time on this issue.

Patch looks good, but it will need a revision bump, Thanks!
Comment 4 Piotr Kubaj freebsd_committer 2017-06-27 07:20:01 UTC
Created attachment 183829 [details]

Corrected patch with PORTREVISION bump.
Comment 5 Richard Gallamore freebsd_committer 2017-06-27 17:41:32 UTC
(In reply to Piotr Kubaj from comment #4)
Would it be possible to change the extension and not edit the .sample file, something like

`map.nopasswd.sample`  <--- this is the only one of these in the pkg-plist and not modified.

The problem as stated in the message correctly is that it will break the pkg checksum data. If instead of using the sample copy, use as a template it will prevent such checksum breakage and equivalents for the other two files. 

There are other ports that do similar procedures but they aren't really the same as with sample config files, and we shouldn't try and mash the two into one mechanism.

Comment 6 Piotr Kubaj freebsd_committer 2017-06-29 13:05:54 UTC
Created attachment 183911 [details]

Did you mean something like this? It doesn't make pkg show any checksum warnings, but I'm quite sure the nopasswd files are not going to be read by DCC. Since each user needs a unique password, it's quite understandable that the files are going to be different across installs.
Comment 7 Richard Gallamore freebsd_committer 2017-06-29 18:05:50 UTC
(In reply to Piotr Kubaj from comment #6)
Yes, but you are correct they wouldn't be read. The .sample would need to be copied to .nopasswd. Also this is just an example, this extension doesn't need to be the chosen one to use.

Do you know if the port uses the .sample hardcoded? or in a config? Hopefully the extension used is set by the script fix-map.

One other query, what are your thoughts on adding this step to the RC script instead of using post-install?
Comment 8 Vernon Schryver 2017-07-02 18:34:56 UTC
> It seems to be an upstream error. 

that is mistaken.  It is an error introduced after I submitted the patch for bug #216799

Please see my comments in bug #216799

>  I don't use DCC as a daemon, so I haven't noticed. Patch will follow shortly with $CHOWN's in Makefile, which will hopefully restore the previous behavior.

Instead of adding a chown to the Makefile, wouldn't it be better to fix the pkt_plist file including the last 3 lines?

The .sample files are FreeBSD inventions that I know nothing about.  The DCC Makefiles create create map, ids, and other files.

The map file is a binary snapshot of DCC server information including round trip times, client-IDs, and passwords used by DCC clients including dccifd, dccm, and dccproc.  As such, it changes constantly.  An initial, default maps file is built by the DCC Makefiles.

A map.txt file is generated and loaded into the new map file by the DCC Makefiles when there is no existing map file.  Thereafter map.txt is merely the output of the command cdcc info.

The ids file is used by the cdcc command to get server passwords and by dccd.  It is not changed by DCC programs other than by the DCC Makefiles creating a new file.  Every installed ids file is likely to be unique because of the generated password that it contains.  Users with DCC servers must change it.  An initial default ids file is also created by the DCC Makefiles.

Fiddling with configuration files in RC scripts sounds undesirable and fragile to me.

Please note that realsoonnow I'll be releasing version 1.3.160.

Comment 9 rwmaillists 2017-07-02 18:51:50 UTC
I'd just like to point out that, as mentioned in bug 216799, the ownership of /usr/local/dcc/ itself is set to root:wheel preventing dccproc from writing new files to the directory.

This was creating an additional error:

dccproc[61386]: lock_open(/usr/local/dcc/whiteclnt.dccx): Permission denied; file not writeable for locking
Comment 10 Richard Gallamore freebsd_committer 2017-07-02 21:12:15 UTC
Created attachment 184018 [details]

After testing these changes supplied by Piotr Kubaj everything appears to be set correctly. This patch is the fixed from the previous one with the last couple of lines @owner and @group removed from the pkg-plist to set the correct DCCHOME directory user/group.
Comment 11 Piotr Kubaj freebsd_committer 2017-07-03 17:29:15 UTC
(In reply to Richard Gallamore from comment #10)
After vjs@rhyolite.com's explanation. it looks ok.
Comment 12 commit-hook freebsd_committer 2017-07-03 17:38:03 UTC
A commit references this bug:

Author: ultima
Date: Mon Jul  3 17:37:56 UTC 2017
New revision: 444972
URL: https://svnweb.freebsd.org/changeset/ports/444972

  * Fix permissions from regression on r443717

  PR:		220201
  Submitted by:	Piotr Kubaj <pkubaj@anongoth.pl> (maintainer)
  Reviewed by:	lifanov (mentor), matthew (mentor)
  Approved by:	lifanov (mentor)
  Differential Revision:	https://reviews.freebsd.org/D11347

Comment 13 Richard Gallamore freebsd_committer 2017-07-03 17:39:26 UTC
Committed, thanks!