Board index » kylix » Re: How to make Kylix application deployment much easier

Re: How to make Kylix application deployment much easier


2004-08-01 01:52:01 AM
kylix2
"Hehe" is NNTP-Posting-Host: 207.105.83.66
"Martin" is NNTP-Posting-Host: 207.105.83.66
Stop morphing, troll.
Simon
 
 

Re:Re: How to make Kylix application deployment much easier

Quote
And for a reason too. Even the dot is removed from a users PATH in the newer
distros. Guess why? Security!
Where exactly is the security issue in having shared objects in your application
directory? If I'm allowed to execute files, it doesn't make a freaking difference.
Quote
Just do not follow the hairbrained Windows
scheme of looking for shared objects in the current or the program
directory. Installation is a task for root and should follow the well
established behaviour UNICES follow in this respect.
This is not the reality. In REALITY, please want, need and are allowed to upload/
install executables inside their home directory. Did you ever hear about a thing
called WEB HOSTING? ;)
This is getting silly.
Simon
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
"Hehe" is NNTP-Posting-Host: 207.105.83.66
"Martin" is NNTP-Posting-Host: 207.105.83.66
Sorry Simon, but 207.105.83.66 is .. :)
They're still proably the same, though
--
Leonel
www.techtips.com.br
"Any fool can write code that a computer can understand. Good
programmers write code that humans can understand." - Martin Fowler
 

{smallsort}

Re:Re: How to make Kylix application deployment much easier

Quote
>"Hehe" is NNTP-Posting-Host: 207.105.83.66
>"Martin" is NNTP-Posting-Host: 207.105.83.66

Sorry Simon, but 207.105.83.66 is .. :)
Yeah, just noticed, too ;)
Quote
They're still proably the same, though
Guess so.
Simon
 

Re:Re: How to make Kylix application deployment much easier

Quote
This is not the reality. In REALITY, please want, need and are allowed to upload/
please = people
 

Re:Re: How to make Kylix application deployment much easier

willi krenn wrote:
Quote

I really can't see the bonus of _not_ loading shared libs in the application
directory. Cluttering the lib directories with all sorts of libraries and
storing the program in different directories and/or writing wrapper shell
scripts ("work-arounds") is better?

Just a few points if I may...
Right, in a theory this sounds plausible and undoubtedly it has some
use, a specially when the application is deployed into controlled
environment as is a single user system or into a dedicated system.
The problem is that Linux by its nature is a network multiuser
operating system, as in any multiuser environment there must be
implemented some security precaution. That's why the system
administrator controls all the as you described “cluttered area?where
shared objects are located. Linux is build around a very simple but
effective schema which permits many properly installed application to
function flawlessly and be used by many users simultaneously . There
are designated areas in the directory/file structure which have
predefined functions (look LSB) and very flexible build in mechanism
to make any application work...
Another important element abut which we should not forget is that the
basic function of shared objects is to be *shared* among many
application which can benefits form them; the idea behind this is to
avoid duplicated code. Of course there are exceptions because some
application may use a very unique shared objects which most likely
will be newer used by any other application on the system; linking
statically is often used in this circumstances which is always better
then to expose unprotected shared objects to a security treat..
Also I would not portray scripts as "work-arounds" because scripts in
Linux have a very important primary role and are very powerful medium
which "glue" together many small specialized, highly efficient and
supper reliable bits pieces of the system.
juliusz
--
InstallMade - Kylix-specific installer
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: How to make Kylix application deployment much easier

willi krenn wrote:
Quote

I can not understand however, why the application directory is not even
looked at when a search over all other paths fails to find the requested
lib.

Because it is unreliable, insecure and it is just completely
unnecessary...what's application directory anyway?
I can see where you are coming from; nobody says that it cannot be
done, that the shared objects be loaded from the application directory
but what is the real benefits of doing this accept perhaps to satisfy
old windows habits? I am aware of the fact that Borland could very
easy build in that capability as default behavior into Kylix but they
didn't do it. Why? Because this is not the Linux way, and it would
create more problems. Surely it would be more understandable for a
window developer to “deploy?Kylix application, but in the same time
it will lead to create bad habits, overall poor security of the system
and effectively to clutter the system with many redundant shared
objects. This approach of course could be used but only as an *option*
for example for testing or in controlled environment single-user
application. But essentially it does not give the developer any
benefits whatsoever, because Linux already has build in far superior
means of doing this in much more *reliable* and *safer* ways. The fact
is that Linux system is designed around the idea that the installed
application location is predefined by the developer/packager and has
to correlate to the system security requirements and other rules and
standards and often the installed files are spread all over the system
in accordance to its respectful functions... by adding another
variable (complexity) to the already complex system will not simplify
things, perhaps on the surface it will, but because this method is
inherently unreliable it can come back and bite you hard in the moment
when you are least expected.
Quote

>Just do not follow the hairbrained Windows
>scheme of looking for shared objects in the current or the program
>directory. Installation is a task for root and should follow the well
>established behaviour UNICES follow in this respect.


Sorry, but as user I want to install non system programs by myself (for
myself) and without the need to become superuser.

Hey! Linux is all about freedom and flexibility and anyone can modify
it to its needs and redefine its basic behavior no problem there...
juliusz
--
InstallMade - Kylix-specific installer
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: How to make Kylix application deployment much easier

Quote
And for a reason too. Even the dot is removed from a users PATH in the
newer
distros. Guess why? Security!
I can understand that for
-) the shell
-) the user root (or any other privileged user)
I can not understand however, why the application directory is not even
looked at when a search over all other paths fails to find the requested
lib.
Quote
Just do not follow the hairbrained Windows
scheme of looking for shared objects in the current or the program
directory. Installation is a task for root and should follow the well
established behaviour UNICES follow in this respect.
Sorry, but as user I want to install non system programs by myself (for
myself) and without the need to become superuser.
Willi
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
Security reasons? Bullshit. What's wrong with having your shared objects
inside your application directory? They are owned by you, and they are run
by your application.
Still does not mean that your executable and/or shared objects can do no
damage. Or your scripts for that matter.
Quote
And DLL hell? If you keep your application DLLs in your application
directory, you don't have a DLL hell. Neither on linux nor on Windows.
Non-issue.
Oh hahaha. The prevailing reason not to look for shared objects in those
places is to prevent all kind of {*word*193} versioning surprises when loading
shared objects. What happens if the order in which shared objects are
looked up is changed as you would like and you start a different program
that depends on another version of the same shared object in another place?
Oops. Why isn't that program working all of a sudden...
Quote
If you wish to be taken seriously, then NAME your "security reasons". Else
I have no other choice than telling you:

The improvement is to remove YOU. For security reasons and for reasons of
avoiding nonsense...
If you can't stand being criticized, what are you doing here? And why ask
the opinion of others? There are several people that have told you that
looking for shared objects in the program directory and/or the current
directory is not done in UNIX other than manipulating LD_LOAD_LIBRARY in a
script. Even Borland does it in that fashion. Scripts are a totally
different matter for the simple reason your sysadmin can inspect them and
ascertain himself that nothing fishy is going on. Inspecting shared objects
is much more difficult. And last but not least, your solution isn't
transparent. It does things out of the ordinary and hides that fact.
--
Ruurd
 

Re:Re: How to make Kylix application deployment much easier

willi krenn wrote:
Quote
Sorry, but as user I want to install non system programs by myself (for
myself) and without the need to become superuser.
That is because you are single-user minded. In this case, experimenting with
a Linux machine at home or in a development environment is quite OK, but
once you go into production work, it is a totally different matter. And
waht is good for developers isn't always good for users. Linux is a
muti-user system, and as a developer you will have to take into account
that there are different standards applied to machines that are used by
users than to machines that are used to develop on.
--
Ruurd
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
This is not the reality. In REALITY, please want, need and are allowed to
upload/ install executables inside their home directory.
Developers maybe. Users? Naaah. In any production environment I have seen to
date users are carefully constrained to a working set of programs they are
allowed to use. Period.
Quote
Did you ever hear about a thing called WEB HOSTING? ;)
Did you ever hear of the concept chroot jail? Do you really think that if
you run a website on a shared machine maintained by your ISP that you have
any possibility of running every program on that host? Don't count on it.
And if you want that, they will probably offer you a dedicated host and if
you need to buy maintenance and/or backup, prices are vastly different.
--
Ruurd
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
>Because it is unreliable,

How is it unreliable?
Well just looking on your code... you base your code on a principle
that the shared objects will be loaded from the application
directory, right? There is a problem right there.. because there is no
a reliable method to determine this particular location (in a sense
you want it) a specially if you use the paramStr(0), I think if you
check (in your code) the /proc file system you may get more reliable
results but not always because for a security reasons the /proc files
system may or may not be visible to your application. There are some
function in Delphi which behave differently on Linux and the Kylix
documentation is very incomplete in this respect. The bottom line is
not to use the paramStr() to determine the path of the executable, it
works on Window not always in Linux. The whole thing could work
perfectly if you assume the location for your application or better
yet to assume a central location for all your application specific
shared objects and follow the Linux installation rules as closely as
it is possible.
Another problem as far I can tell is that your code attempts to load
the shared objects from the application directory last (when the
Linux loader is not able to find it in the system), right? OK you
shouldn't do this. I think it would be much better if you revers the
process and check the application directory first because otherwise
you may load inappropriate version of the library and the application
will crash.
Quote

>insecure

Where exactly is the security issue?

Security, well I will not deliberate on this much because security is
just a stage of mind if you think it is perfectly secure then it is
secure - for you that is. All I can tell you that it is not a safe
way of doing things but you do not have to hold my word for it. :)
Quote
>and it is just completely
>unnecessary...

Google for "kylix deploy". Or check the newsgroups archives.
Well, I am perfectly aware about the Kylix deployment issues and I
have personally dedicated a lot of time and effort to help a lot of
people in this respect and in attempt to increase the Kylix
acceptance. It would be prudent to say that from my observation all
the deployment problems related to Kylix 1 Kylix 2 and partially Kylix
3 originated from the “conceptual mistake?of not following Linux
shared objects naming convention. The lesson to be learned is that it
is extremely important to follow the Linux way of doing things ;)
Quote

Or simply try to write a CGI application in Kylix and get it to run
at your webhost.

Well, CGI surely you could benefit in there but there is really no
problem with CGI because you always can load the needed libs using an
absolute path since in the CGI scenario all the locations of the CGI
binary and libs are well known in advance. There is no need to
determine the application directory because it is all known.
Quote
>I can see where you are coming from; nobody says that it cannot be
>done, that the shared objects be loaded from the application directory
>but what is the real benefits of doing this accept perhaps to satisfy
>old windows habits?

You are able to run Kylix applications without any installation process.
You are able to run Kylix applications without manual work by a sysadmin.

Simon
Sure, I am able to do all these for over two years, as well as
thousands of other Kylix users.
juliusz
--
InstallMade - Kylix-specific installer
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: How to make Kylix application deployment much easier

Quote
>Security reasons? Bullshit. What's wrong with having your shared objects
>inside your application directory? They are owned by you, and they are run
>by your application.

Still does not mean that your executable and/or shared objects can do no
damage. Or your scripts for that matter.
Where is the logic in all that? The whole discussion is about deploying Kylix
application to Linux boxes. Yes, running an executable file, a script or
a shell is a security risk. But without it, your shiny Linux box is pretty
useless. It simply does not matter if there is a shared object right next
to my application. There is no difference in security. So what is your point?
Quote
>And DLL hell? If you keep your application DLLs in your application
>directory, you don't have a DLL hell. Neither on linux nor on Windows.
>Non-issue.

Oh hahaha. The prevailing reason not to look for shared objects in those
places is to prevent all kind of {*word*193} versioning surprises when loading
shared objects. What happens if the order in which shared objects are
looked up is changed as you would like and you start a different program
that depends on another version of the same shared object in another place?
Oops. Why isn't that program working all of a sudden...
What happens if the admin of the box decides to replace or remove a specific
shared object on a box? This is more "DLL hell" than having your so in
your applications directory.
Quote
If you can't stand being criticized, what are you doing here?
I'm open to any kind of critics, as long as it has any value.
Up until now in this thread, I was told:
"You've got to be kidding! It can be hardily called a solution.
This code will fail more often then not "
"it's pretty dire coding."
"The improvement is to remove the code. For security reasons and for reasons
of avoiding the same nonsense as on Windows called DLL-hell."
No facts, no real arguments, just lots of "it sucks because I say so" kind of
comments.
Quote
There are several people that have told you that
looking for shared objects in the program directory and/or the current
directory is not done in UNIX other than manipulating LD_LOAD_LIBRARY in a
script.
Wow, who would have thought that. Yes, that's how it's usually done on UNIX/LINUX.
But oh well, unix applications usually also do not deploy their own shared objects.
The stuff in /usr/lib and friends is used by common shared objects.
And now back to the reality: Borland requires us to ship a bunch of SOs with our
applications that are no use to anyone else on the box than our application. Yes,
in UNIX world you would normally statically link those objects. We can't do that.
And that's why a work around is needed.
Quote
Scripts are a totally
different matter for the simple reason your sysadmin can inspect them and
ascertain himself that nothing fishy is going on. Inspecting shared objects
is much more difficult. And last but not least, your solution isn't
transparent. It does things out of the ordinary and hides that fact.
This is not reality. In reality, what counts is what my application does (e.g.
eat system resources, flood the network, whatever), not which SOs it loads.
And even if the sysadmin would like to find out which SOs I'm loading: ldd exists.
And there is no difference in reading my startup script or just looking at the
applications directory listing.
Simon
 

Re:Re: How to make Kylix application deployment much easier

Quote
>This is not the reality. In REALITY, please want, need and are allowed to
>upload/ install executables inside their home directory.

Developers maybe. Users? Naaah. In any production environment I have seen to
date users are carefully constrained to a working set of programs they are
allowed to use. Period.
*sigh*
If the user is not allowed to install applications, it does not matter how
the application he's unable to install would load it SOs.
OTOH, if he IS allowed to install applications, the sysadmin probably will be
happy that the user does not have to bug him to install some weird SOs he has
never heard about into /usr/lib.
Quote
>Did you ever hear about a thing called WEB HOSTING? ;)

Did you ever hear of the concept chroot jail? Do you really think that if
you run a website on a shared machine maintained by your ISP that you have
any possibility of running every program on that host? Don't count on it.
I don't know what universe you are living in. In mine, all web hosters allow
the execution of CGI binaries since at least 10 years now.
Simon
 

Re:Re: How to make Kylix application deployment much easier

Quote
I don't know what universe you are living in. In mine, all web hosters allow
the execution of CGI binaries since at least 10 years now.
....and only VERY few (next to none) will be installing third party SOs into /lib,
just because your CGI needs them.
This is the REALITY kylix developers are facing when trying to deploy their kylix
made CGI to a webserver. And my work-around solves it.
Simon