Re: compile+link Fujitsu Linux

On Feb 8, 3:55 pm, Robert <n...@xxxxxx> wrote:
On Wed, 6 Feb 2008 20:13:38 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:

Robert wrote:
On Wed, 6 Feb 2008 00:19:14 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:

On Feb 6, 7:01 pm, Robert <n...@xxxxxx> wrote:

Well, no it doesn't do that. Not even close. But you still haven't
explained how your mechanism is 'better'. Given equal slackness in
permissions and such and users can access compilers then how is a
library any different ? Tools can push and pull stuff out of
libraries.

My security is better because it does not depend on file system permissions. It doesn't
depend on application code, either.

You claimed that your mechanism of having all the programs in one
library was better. That is was more reliable, more secure, easier to
deploy and faster.

It may be insignificantly faster in the CALL, but is slower on
startup. Deployment would only be 'easier' if you don't bother to
test. Reliability is worse because a 'missing file' stops the whole
application. Now you simply change the subject to something that is
completely independent of whether it uses libraries or individual
programs.

I talk about packaging called programs, you respond with security concerns.

No Robert, it was you that started with 'security'.

I respond to
those security concerns, you say it is irrelevant to packaging.

To me, security and packaging ARE unrelated. To you, they are related because you are
using file system permissions as program permissions. So long as you do that, you MUST use
dynamic loading. The security tail is wagging the program loading dog.

Actually I was using dynamic loading long before there were security
concerns, or indeed facilities to do so. Using file system permissions
was a bonus.


The goal of security is to prevent unauthorized people from seeing or changing certain
data. I do that by protecting the DATA; you do it by preventing them from running
programs.

As an analogy, suppose we are parents who want to prevent our kids from watching sex
movies on TV. You would do it by locking up the remote control, which is easily bypassed
with a universal remote. I would do it by telling the cable box to play the movies only
for designated users.

You claimed that your way was superior and the best that you have come
up with is 'less ugly'.

Simpler deployment, can be checked by auditing tools, faster loading, more reliable
because mid-run aborts due to missing program are impossible.

These are mere assertions. Having a script to do ZIP up everything is
just as simple as having a list for ld. Actually the ZIP list can be
*.so, so that is simpler and more reliable because it collects
everything and not just what is in the list of -ls. On unzipping it
won't remove a file that failed to be included in zip, while a library
short of one program will make that unavailable.

It is dangerous to use wildcards when building distribution packages such as zip or
library. You can inadvertantly include an untested version,

As you pointed out when I said that you might include an untested
version in your library: untested versions don't get to the issue
directory.

an experimental test version,

Won't get to the issue directory.

even a trojan. A list guarantees that every component in the distribution package went
through the testing and review process.

But you are packaging up everything in the library, not just a list of
new stuff.


The faulty lists I mentioned earlier are fixed in the first test cycle. After that, the
list does not change unless a newer version is linked to a defect report, code review and
test results.

'Simple' is 'what you are used to'. It may be simpler for you because
you already have it all set up. My way is simpler for me because I
have mine set up. You are attempting to claim some sort of 'global
universal truth' for your assertions (as usual).

I'm claiming that dynamic program structure is the norm and the default.

It may well be that in your cubicle.

.

Relevant Pages

  • Re: Whatever happened to Site Groups in WSS 3.0?
    ... Team Members) then break the inheritance of permissions on certain lists ... libraries and apply different permissions at this but this would be ... Site Groups worked at the site collection level and Site Groups worked ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Whatever happened to Site Groups in WSS 3.0?
    ... Team Members) then break the inheritance of permissions on certain lists ... libraries and apply different permissions at this but this would be ... Site Groups worked at the site collection level and Site Groups worked ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: How to find out access permissions for files?
    ... libraries. ... > permissions for (based on NTFS security). ... > will not click on files that he does not have access rights for, ...
    (microsoft.public.dotnet.security)
  • Re: Refusing all permissions
    ... libraries which has extremely tight security (the libraries should refuse ... and see what permissions it is getting. ... Assembly declarative requests could be used for either one of the ...
    (microsoft.public.dotnet.security)
  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... Reliability is worse because a 'missing file' stops the whole ... completely independent of whether it uses libraries or individual ... take longer because you also load the library. ...
    (comp.lang.cobol)