[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any progress with FIS GT.M?



On Tue, 19 Jun 2012, Bhaskar, K.S wrote:
> >owned by root who is the one with ability to revert that anyways?
> [KSB4] Having installed files be read-only is good hygiene.  

I have heard that excessive sanitation leads to weaker immune system and
allergies ;)  but in general in Debian we just follow
http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
"Files should be owned by root:root, and made writable only by the owner
and universally readable (and executable, if appropriate), that is mode
644 or 755. " and so on

> With
> the possible exception of the gtmsecshr that resides in $gtm_dist, I
> don't think any other process checks or relies on the installed
> files being read-only.

> Note that the files may be have a non-root group.

should we work toward creating/reserving a dedicated group for
fis-gtm?  I thought that for now we would just have everything
root.root... but due to the root-suid may be a dedicated group might be
a reasonable thing

> >I guess they shouldn't just be ignored, right?  but those .c's are the
> >original sources which aren't installed with the "stage1" installation --
> >is that just some legacy pieces in configure or am I missing smth?

> [KSB4] I think that is because we (maybe Amul?) changed the
> packaging of the database encryption plugin at the Hackathon.  Note
> that the plugin always goes out with full source code even in GT.M
> binary distribution because even if someone doesn't want to
> recompile GT.M (most users don't) they may want to recompile the
> encryption plugin to use openssl instead of libgrcypt, for example,
> or to tweak it to connect to their site's key management.

well, for any rebuilds they always would have an opportunity to apt-get
source and then dpkg-buildpackage after modifications... As for openssl
-- I guess we can't just provide a choice of prebuilt encryption plugins
due to openssl's license conflict with GPL (although with an additional
exception [1] that could be feasible!).  But then again -- a clear
description in README.Debian telling to do apt-get source  and taking
source.tar or just a straight source tree from there would imho be more
beneficial and reduce the size/pollution of default fis-gtm
installation.  So IMHO there is no reason for source.tar under
/usr/lib... worse come to worse and if you insist -- we could ship it
under /usr/src/fis-plugin-encryption.tar.gz ;)

[1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        


Reply to: