Re: compile+link Fujitsu Linux

On Feb 4, 7:35 pm, Robert <n...@xxxxxx> wrote:
On Sat, 2 Feb 2008 21:33:22 -0800 (PST), Richard <rip...@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.

Why can't you ensure that the environment is set correctly before it
runs. In any case if the run won't find anything because the paths are
set wrongly (which doesn't happen to me) then my core routines won't
be found either and the program won't start either.

But your point was about files being deleted or corrupted. Now you try
to change to having stuff mixed up.

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

I am not sure why you are attempting to change the way that I (and, it
seems, Charles) have been working for years. The way I do things
things works 100% safe and reliable. You cannot claim anything better
than that, _plus_ I get flexability thay your mechanism doesn't give.

I was was doing batch jobs then maybe I would do that, or even
static. But I don't so what batch jobs do is of no interest.


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.

<shrug> I don't need multiple concurrent versions. The way I do it
works 100%.


The benefit is that you won't accidentally get a library installed by another application.

I never will because all my files are held in a structure of
directories that will never be used by anything else.

Why do you keep coming up with entirely spurious arguments and straw-
men ?

This a common problem on Windows, known as 'DLL hell'. The disadvantage is inability to
upgrade a library without upgrading the calling program.

Your point being ?

Again you create a spurious argument and a straw-man.

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.

Why do you think that relevant ? I haven't recompiled 'the calling
program' for years.


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.

You weren't paying attention. I did an _actual_test_ and all users
_did_not_ have to CANCEL before replacement (but then this isn't
Windows).


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

What makes you think that users have write access to the program
directory ? _I_ can drop in another program.

Just another straw-man.

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.

Just change the subject then. You were trying to say that using
libraries was 'more secure'. You tried to say that 'home-grown' was
not secure.

Now you just change the subject to something different because you
failed to establish your unsupported and flawed assertions.

In fact this change seems to be after I pointed out that your
mechanism _couldn't_ use the unix file system security because it
would stop your applications from starting.

There is nothing in using dynamic loading that prevents the
application from using any other security mechanism.

In fact my system does implement field level security within the
system, but I don't run Banks or Stock Exchanges. The level of
security that I use is exactly correct for the businesses that use my
applications.


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.

Another straw-man. Why would I have setgroupid set ?

But as you _should_ have noticed I don't need to "Rely on Unix file
system". I have the 'home-grown' application security that you said
was useless, and now you say that Unix is useless and you would use
'home-grown'.

You really are struggling (and failing) to score any wins here at all.

The point is that with the high granularity I _can_ use Unix file
system security (and have it work) as well as the application
security.

.

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
    ... been using dynamic load when required for some some decades. ... libraries when first called. ... That's what version control is for. ... Now you're advocating home-grown security. ...
    (comp.lang.cobol)
  • Re: managed string library
    ... respective libraries as well. ... more focussed on functionality and ease of use or "Software Crisis" ... Another security issue is the question of auditing. ... code of Bstrlib) and 2) verifying that the facilities claimed are ...
    (comp.lang.c.moderated)