Re: compile+link Fujitsu Linux

On Mon, 4 Feb 2008 00:04:01 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

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

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 wasn't trying to change your way of doing things, I was answering Charles' question.

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.

In my world, Cobol are nearly all in batch jobs. User interface is in Java or occasionally
PowerBuilder.

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 ?

YOU brought up replacable files as an advantage.

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 you're feeding it the program name via database, you could just as easily give it the
version string. That wouldn't require a recompilation either.

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.

If they have read access, they can copy your whole directory structure to their home
directory, change permissions all they want, and run their local copy to find out the
boss' salary.

How do you know they can't do that? Is computer illiteracy a job requirement? Are the
tested for lack of knowledge before hiring?

Security that depends on user ignorance is so 1980s.

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.

YOU introduced application security, not I.

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.

I worked with a system admin whose first job, after getting a degree in computer science,
was night manager at a Wal-Mart, where he ran the back-office computer. When the help desk
was talking him through a problem, they were giving him the root password on THEIR SERVER.
He knew exactly what that meant. He said, "What a gaping hole. I could have done
anything." He didn't; someone else might have.

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 ?

Because a user set it. If it's set on your main menu, every program in the system has the
menu owner's group permission. Unix holds it in Previous Group Perission.

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'.

I said not to use home-grown security. Imagine a shop with 100 applications, each having
its own quirky security. It would be impossible to administer.

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.

I wonder if that French bank said the same.
.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... the Unix and Windows worlds. ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Security that depends on user ignorance is so 1980s. ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • 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: What protects Unices from Virus like attacks ??
    ... >> what protects all Unix machines from such similar problems. ... > If a vulnerability is found for Unixen, ... I met security engineers that were aghast at some of the ... Many MS customers don't know what to do ...
    (comp.unix.questions)
  • Re: What protects Unices from Virus like attacks ??
    ... >> what protects all Unix machines from such similar problems. ... > If a vulnerability is found for Unixen, ... I met security engineers that were aghast at some of the ... Many MS customers don't know what to do ...
    (comp.unix.programmer)
  • Re: RWW Security was compromised.
    ... Windows server security as my previous experience is Unix. ... > One of our clients RWW was compromised over the weekend. ...
    (microsoft.public.windows.server.sbs)