Bug 66933

Summary: fix port: secirity/sfs
Product: Ports & Packages Reporter: Yen-Ming Lee <leeym>
Component: Individual Port(s)Assignee: Pav Lucistnik <pav>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
sfs.diff none

Description Yen-Ming Lee 2004-05-20 10:50:27 UTC 
- add files/patch-nfsclient and unbreak this port
- use UID/GID other than 71:71 which is registered by oracle already
- add USE_LIBTOOL and remove *.la in PLIST
- minor fixes in PLIST
Comment 1 Pav Lucistnik freebsd_committer freebsd_triage 2004-05-21 23:43:53 UTC 
Dear maintainer of FreeBSD port security/sfs, please take a look at

http://www.freebsd.org/cgi/query-pr.cgi?q=66933

Do you approve this patch?

-- 
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

An arrow (+0,+0) {@f0} finds a mark. It dies.
Comment 2 Pav Lucistnik freebsd_committer freebsd_triage 2004-05-21 23:43:56 UTC 
State Changed
From-To: open->feedback

Asked maintainer for approval.
Comment 3 Pav Lucistnik freebsd_committer freebsd_triage 2004-05-21 23:43:56 UTC 
Responsible Changed
From-To: freebsd-ports-bugs->pav

Handle
Comment 4 Michael Handler 2004-05-22 00:07:43 UTC 
> http://www.freebsd.org/cgi/query-pr.cgi?q=66933

I have no problem with the LIBTOOL/remove *.la portion, or the
PREFIX vs LOCALBASE fix, or the DOCSDIR portion.

The nfsconf.h patch looks fine, but does it break compilation on
4.*? I can test if the submitter hasn't, it just takes 30+ minutes
to compile SFS on my 4.* machine.

Re: the uid/gid change, I don't have any real objection, but is
there a registry for these things I'm not aware of, so we can change
the UID/GID once and not deal with it again? I looked around when
I was writing the port, and I didn't find any.

I reject the following portions of the plist patch:

1) adding etc/sfs/sfs_host_key to the packing list. This file is
   unique per host and precious -- it shouldn't be packaged, and
   it certainly shouldn't be removed when the package is uninstalled,
   that would change the advertised SFS path. (Just like an ssh
   host key.) Correspondingly, the rmdir of etc/sfs is rejected as
   well; it'll always fail due to the existence of sfs_host_key.

   Note that pkg-deinstall attempts an rmdir of etc/sfs and prints
   a message suggesting that the administrator investigate the contents
   and remove the directory if they're done with SFS for good. (Rather
   than just temporarily removing the package to upgrade it.)

2) The @group statements wrapping suidconnect are necessary
   to preserve the correct gid ownership of the file (it's setgid)
   when installing from a package tarball.

Other than that, looks good, thanks for the work. I don't have a
stable 5.* machine to test on right now, which is why I haven't
fixed it.

-- 
michael handler
washington, dc
Comment 5 Pav Lucistnik freebsd_committer freebsd_triage 2004-05-22 00:29:33 UTC 
State Changed
From-To: feedback->closed

Committed with respect to feedback stated by maintainer