Re: compile+link Fujitsu Linux

On Feb 5, 6:52 pm, Robert <n...@xxxxxx> wrote:
On Mon, 4 Feb 2008 00:04:01 -0800 (PST), Richard <rip...@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.

When I looked at Charles question _I_ saw that it contained the
requirement to get CALL/CANCEL working. _Nothing_ that you have
suggested has been to meet that requirement.


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.

That may be why your suggestions don't match the requirements.


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.

Your claim was: "The benefit is that you won't accidentally get a
library installed by another application.".

In what way does _your_ mechanism do this ? If you libraryize your
programs and version them what is it that prevents another application
choosing the same name and having the same version and 'accidentally
installing that over yours' ?

You make claims about what may happen and seem to completely fail to
notice that the same problem could occur to your system. You claim a
completely spurious 'benefit' for your mechanism without knowing what
my mechanism actually is.


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.

And I could even more easil;y just continue to use what has worked
well for me for decades without your unwanted complexifications.


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

The users would _also_ need to have access to a compiler and to the
specifications of the framework, or the source code of that, to know
what 'mylogin' must do when a user logs in.

You may as well claim that "anyone can write their own Unix login and
get root access".

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.

Well, actually, no they couldn't. I already told you that particular
programs can be set to be owned by the application administrator with
a group id of the trusted group and permissions of 640. It is only if
you are a member of the trusted group that give read access to run (or
copy) that program. Users can be members of several groups so access
can be very granular. Users not a member of that group will get a
'program not found' if they try to select it from the menu.

If the library was required at start up (as in your mechanism) then
the application would fail to do anything for users not in _all_ the
trusted groups. Also you gather several programs into one library so
you have less, or no, usable granularity.

I thought that you claimed to be some sort of Unix guru, yet you seem
to need to have these simple things explained to you.


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.

Your arguments always seem to degrade to the level of drawing
unwarranted conclusions from stuff that you just make up while you
completely ignore what you are told.


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.

No, that is wrong. I was saying that "the CALL dataname feature is
invaluable ..".

Then, out of the blue, you changed this to: "Now you're advocating
home-grown security."


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.

The relevance of this little anecdote is ?

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.

Excuse me, but how did a user get to set this ?

Building straw-men to sit on straw-men's shoulders doesn't win any
arguments here.

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.

If I had some ham, I'd have ham and eggs, if I had some eggs.


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.

Do you mean is they started with "I don't run Banks or Stock
Exchanges" ?

.

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
    ... just as Charles reported. ... In the late '90s POSIX became the Unix standard. ... LD_LIBRARY_PATH is used to load dynamic libraries at run time. ... can 'front end' the search path. ...
    (comp.lang.cobol)
  • 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. ... But I don't so what batch jobs do is of no interest. ... Security that depends on user ignorance is so 1980s. ...
    (comp.lang.cobol)
  • 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)
  • 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)