Bug 66933 - fix port: secirity/sfs
Summary: fix port: secirity/sfs
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Pav Lucistnik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-20 10:50 UTC by Yen-Ming Lee
Modified: 2004-05-22 00:29 UTC (History)
0 users

See Also:


Attachments
sfs.diff (3.59 KB, patch)
2004-05-20 10:50 UTC, Yen-Ming Lee
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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