Re: Any progress with FIS GT.M?
On 06/19/2012 11:43 PM, Yaroslav Halchenko wrote:
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
[KSB5] The default for GT.M has for a long time been read only for all,
including the owner. But I agree that if the Debian package chooses to
install as owned by root and read/write for root, that works.
Although the default for a GT.M installation is to make it world
executable, we do have users who wish to limit execution to members of a
group. In this case, they would install it not world readable. But it
is always installed with no write permissions.
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
[KSB5] That seems a reasonable goal. I don't know what it takes to set up
a default "gtm" group for Debian releases.
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 ;)
[KSB5] No objection. Alternatively, create a separate package for
fis-gtm-enc-plugin or some such. This does seem to be making things more
complicated right now, not simpler, but you are going the packaging.
Regards
-- Bhaskar
[1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Reply to: