Hi Alan,
thanks for the more detailed explanation.
On Sun, Aug 29, 2010 at 05:38:06PM -0400, Alan O'Neill wrote:
Hi Andreas,
To explain further about the directory permission thing, when I built
the Debian package, I started by running GT.M's 'config' script,
installing GT.M into the directory /usr/lib/fis-gtm/V5.4-000A_x86. I
answered the installation questions as follows:
File owner: bin
Because I was not sure about the system user bin myself I asked on
debian-mentors list. I'm hereby quoting the answer[1]:
HELP: No files on my system are owned by user or group bin. What
good are they? Historically they were probably the owners of
binaries in /bin? It is not mentioned in the FHS, Debian Policy, or
the changelogs of base-passwd or base-files.
LSB 1.3 lists bin as legacy, and says: "The 'bin' UID/GID is
included for compatibility with legacy applications. New
applications should no longer use the 'bin' UID/GID."
The Debian Policy Manual also includes a statement about file
permissions and owners in section 10.9:
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.
Directories should be mode 755 or (for group-writability) mode
2775. The ownership of the directory should be consistent with its
mode: if a directory is mode 2775, it should be owned by the group
that needs write access to it.
Following this advise I would recommend instead of using user bin
just to create a new system user via
adduser --system gtm
(or some more reasonable user name) and use this one in the installation
questions.
Unicode support: yes
ICU version: 4.2
Lower case versions of MUMPS routines: no
The config script sets up the the following directories with 'r-xr-xr-x'
(i.e. not writable) permissions:
- V5.4-000A_x86
- V5.4-000A_x86/utf8
- V5.4-000A_x86/plugin
- V5.4-000A_x86/plugin/gtmcrypt
- V5.4-000A_x86/plugin/gtmcrypt/utf8
Additionally, some of these directories contain symbolic links. If I
build the Debian package and maintain the non-writable permissions on
the directories, when someone wishes to extract the package (dpkg -x)
without root privileges,
Do you have any practically relevant case in mind why someone without
root privileges should wish to extract the content of the package
manually?
they get errors because the directories do not
have write permission. So what I did was change the permissions on
these directories to rwxr-xr-x in the Debian package. When the actual
install occurs, the 'postinst' script does a chmod to put the
permissions on these directories back to r-xr-xr-x. I took this step
because Bhaskar had requested that the package be extractable without
root privileges.
Bhaskar, could you please elaborate more detailed on this requirement?
Perhaps there is another solution for this instead of playing around
with permissions in an unusual way.
You mentioned that I should not rely on the user ID of any user. I was
concerned about that too, which is why I placed the two following
commands at the end of the postinst script:
chown -R --from=0:2 root:$owner "$version"
chown -R --from=2:2 $owner:$owner "$version"
On my system, the value of '2' is assigned to user bin and the value of
'0' is assigned to root. (I suspect root is always assigned the value
of zero, but just in case... :) This way, I ensure that the ownership
is correct, regardless of the value assigned by a particular system.
If I'm not missleaded only the UID 0 has a special meaning and enables
the user with this ID to superuser powers. *Usually* (but not
necessarily) this user is called root. (IMHO, you can give this user
any name, only the UID is checked - but that's an academical issue). To
my knowledge no other UIDs are guaranteed to have any special meaning
and as written above the use of user name bin is deprecated.
Regarding 'svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk'
and the GT.M scripts that I referenced, I wasn't trying to get into too
much detail about them right now. (I wouldn't mind doing it, but I
didn't want to muddy the waters.) I was just wondering whether everyone
was okay with the idea of using update-alternatives to link the Fidelity
supplied script of '/usr/lib/fis-gtm/V5.4-000A_x86/gtm' to the name
'gtm-su' (instead of simply 'gtm').
I personally have no problem with gtm-su. It is just a name and if you
regard it as useful it is fine for me.
My thought is that since the
Fidelity supplied script named 'gtm' uses a database that is in the
user's home directory, it's more similar to a single-user version of
GT.M (i.e., if the system is setup so different users cannot access each
others home directory, then effectively GT.M becomes single user). So I
thought it might be good to rename that script, so to speak, as "gtm-su"
(single user) and then later publish a script called "gtm" that allows
users to enter a specific GT.M environment that is accessible to
multiple users.
Reading this the name sounds reasonable choosen even if I do not finally
understand this signle-/multi- user issue.
I definitely agree that it's tough with just the postinst script. I'd
be happy to share more, but I need some help on that front.
Specifically, I'm wondering what is th
At first you need to ask for a guest account on alioth.debian.org
(development machine for Debian developers) and once you have created
this you should ask for beeing added to the Debian Med project. This
will grant you commit permissions to the SVN mentioned above.
Interesting readings are:
1. Debian Med policy document:
http://debian-med.alioth.debian.org/docs/policy.html
2. Handling of SSH keays on Alioth
http://wiki.debian.org/Alioth/SSH
(provides a problem - solution scenario for the most frequent
problems in accessing Alioth
3. Access of SVN on Alioth
http://wiki.debian.org/Alioth/Svn
alternatively Git (in case you prefer Git over SVN)
http://wiki.debian.org/Alioth/Git
Thanks much for your thoughtful response. I look forward to hearing
from you again soon.
Thanks for your work on this
Andreas.
[1] http://lists.debian.org/debian-mentors/2010/08/msg00340.html