Re: compile+link Fujitsu Linux

On Sat, 2 Feb 2008 21:33:22 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

On Feb 3, 3:31 pm, Robert <n...@xxxxxx> wrote:
On Fri, 1 Feb 2008 12:58:23 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:

Loading at start up time is faster and safer.

That is your opinion. It doesn't agree with mine at all, and I have
been using dynamic load when required for some some decades.

You can specify -z lazyload to make it load
libraries when first called.

It may be that for a batch run checking that all required modules are
available at start-up would be useful. However, for an interactive
system with several applications and many modules it would be _slower_
on start up to load all modules simply because many will not be run on
any particular day.

As for 'safer', you have that completely wrong, too. If a particular
module is missing then it would prevent anyone doing anything if the
startup failed because of that, but it may be a module that is not
actually required that day.

As I never have had an issue where any system was 'unsafe' because I
had separate dynamic loaded programs then I can't see how you can
claim 'safer' than that.

It happens to me often, because I frequently change environments. If the right .profile or
..login doesn't get sourced in, the library path will be blank or incorrect. I find it
helpful to know in advance that a program or batch job will not run, instead of having it
abort in the middle.

Others reached the same conclusion, which is why dynamic program structure is THE NORM in
the Unix and Windows worlds.

dynamic link structure Cobol style Load On Demand

Exactly, they are _loaded_ dynamically. The requirement was stated as
being the last: "dynamic linkage" which does dynamic loading. You
should have noticed that the DLOAD directive was used and thus the -l
was inappropriate (see table in manual).

Fujitsu works with DLOAD and dynamic program structure, because dlopen() finds programs
already resident. If the program is NOT resident then it loads from disk. The only
downside is Fujitsu will not CANCEL programs bound at start up time.


No. The downside is that the user has to completely close the
application, update the libraries, and then restart the application if
a new program, or an updated one, or a one-off, is required.

An application can do that with versioning. If it calls foo.1.3 and foo.1.2 is already in
memory, the loader will not use 1.2, it will load 1.3.

The benefit is that you won't accidentally get a library installed by another application.
This a common problem on Windows, known as 'DLL hell'. The disadvantage is inability to
upgrade a library without upgrading the calling program.

Version binding is normally done by the linker; it is normally not coded into the calling
program, thus you don't have to recompile the caller to change its binding, but you do
have to reload it. However, versioning can be controlled by the program by using the
dlvsym() function.

If it is Windows then the library cannot be replaced until all users
have closed the application because you cannot overwrite an open file.

Dynamically loaded dlls have the same problem. All users have to CANCEL before the dll can
be replaced.

The Unix solution is to put the version number into the file name. The library name with
no version is a symbolic link to the current library file. You can change symbolic links
at any time because the file system doesn't track whether they are in use.

With dynamic loading, and a suitable framework in place (which I had
developed many years ago), it is only necessary to drop the new
program in and select it.

Sounds like a golden opportunity for hackers.
mv login.so login.bkp
cp mylogin.so login.so
echo Ready for unauthenticated login.
.....
mv login.bkp login.so

Actually, to those that use this, it _simplifies_ deployment,
especially in bespoke systems where I operate. If a single program
requires changes then only that file is tested and redistributed. In
any rational development all deployments would be fully tested. If you
link several programs into one library the all those in the library
need to be retested. If they are all linked to one executable then
everything needs to be retested.

There is no reason to re-test an unchanged program just because it is in the same library
with other programs.

Yes, there is. Any program that is re-issued must pass testing. It may
be that other programs in that library have been modified (by someone
else) but are not completed and ready for distribution.

Changes in one program can't cause errors in other programs unless they share global data.

You are changing one program and then collecting a dozen, or several
dozen into one library file and re-issuing it. How do you ensure that
the other dozens have not been changed but are not ready for issuing
yet ?

That's what version control is for. Untested programs don't get moved to the trunk
(production).

And the CALL dataname feature is invaluable as it means that the menu
program can use a data file to define what is available in a
particular application, or even to the particular user, and this can
be extended by changing the data file (and issuing the programs)
without changing the menu program at all.

Now you're advocating home-grown security. I've seen hundreds of home-grown security
systems and not one of them was secure. Most can be defeated by editing a cleartext
database or text file.

'Home-grown' or application security does not prevent other security
systems being used. In fact having each program separately in its own
file can be used to give greater granularity to the security.

In any case, in my systems, users don't have access to the application
security files except by running the application control system and
that is protected. And, no, they can't just edit a text file.

So you are inventing straw man arguments yet again.

If I want some programs, such as month end, to be entirely secure I
can make put them in a special group and only have specific users in
that group. Make them readable by that group only and no one else can
run them even if they break the application security.

With your mechanism:

1) You would have to make the whole library special group only (OK so
you could reorganize and re-issue).

2) the application would fail to start for everyone else because the
library was unavailable.

My mechanism is oriented around data, not programs. If I want to protect month-end figures
in the accounting system, for example, I protect those numbers in the database.
Unauthorized users cannot change them by running the monthend program, by writing their
own program nor by running a database utility. Your notion of security by controlling
access to programs was obsolete twenty years ago.

If I DID want to limit access to a program function, the security check would be in the
function, not the file it is packaged in nor the calling program. Relying on Unix file
system to do application security is weak. For example, if the setgroupid bit of a program
file is set, it executes under the owner's group id rather than the user's.


.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Charles was unfamiliar with Fujitsu on Unix. ... libraries was 'more secure'. ... YOU introduced application security, not I. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... completely independent of whether it uses libraries or individual ... take longer because you also load the library. ...
    (comp.lang.cobol)
  • [UNIX] XDR Integer Overflow (Additional Details)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... were discovered in these libraries during the testing of new Retina ... locally audit applications for the existence of common vulnerabilities. ...
    (Securiteam)
  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... You would do it by locking up the remote control, ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... been using dynamic load when required for some some decades. ... libraries when first called. ... file can be used to give greater granularity to the security. ... mechanism _couldn't_ use the unix file system security because it ...
    (comp.lang.cobol)