[Gambas-user] Test Module, First try

Sat Aug 15 01:49:47 CEST 2020

Hi,

Attached is the latest version with the more robust search functions as follows

1) $XDG_DATA_HOME/gambas3/lib/<vendor>/<name>:<version>.gambas             - if present
2)  ~/.local/share/gambas3/lib/<vendor>/<name>:<version>.gambas            - if XDG_DATA_HOME not found
3) (ALL PATHS IN $XDG_DATA_DIRS)/gambas3/lib/<vendor>/<name>:<version>.gambas - if present
4) (All PATHS IN $LD_LIBRARY_PATH)/gambas3/<vendor>/<name>:<version>.gambas   - if present
5) /usr/lib/gambas3/<vendor>/<name>:<version>.gambas                       - if present          
5) /usr/lib/<System.Architecture>/gambas3/<vendor>/<name>:<version>.gambas - if present
5) (ALL PATHS IN $PATH)/<vendor>/<name>:<version>.gambas                   - for backwards compatibility

Closer I think

Brian G

----- Original Message -----
From: "Brian" <brian at westwoodsvcs.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Friday, August 14, 2020 9:20:52 PM
Subject: Re: [Gambas-user] Test Module, First try

Hi,

The ide if used to build an installation package, seems to always install the library to a subdirectory of the /usr/lib/gambas3 by default ... so I am a little confused?

1) I have to discover then where the ide gets the correct path during package generation... OK
2) My Hacker mind sees many ways but, your right I think I will forget about security stuff
3) I am not using absolute paths unless I need a default. using XDG_DATA_HOME and XDG_DATA_DIRS if available now
   The entry gbs3 makes into the .project file is an absolute path after it locates the correct lib according to the search order.
   This path is regenerated upon each execution of the script.
4) It looks like I have some homework reading to do this weekend...lol
5) And a final search point as the /usr/bin directory, or should it correctly be the $PATH if executables  can also be libraries?

Thanks

Brian G

----- Original Message -----
From: "Brian" <brian at westwoodsvcs.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Friday, August 14, 2020 1:46:56 PM
Subject: Re: [Gambas-user] Test Module, First try

if they have a user account on a server and run a management script

Thank You
Brian G

----- Original Message -----
From: "Bruce" <adamnt42 at gmail.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Friday, August 14, 2020 1:36:36 PM
Subject: Re: [Gambas-user] Test Module, First try

Things you should be aware of:
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
https://en.wikipedia.org/wiki/Rpath and
https://www.tecmint.com/understanding-shared-libraries-in-linux/ (if you 
have a good browser thata eliminates ad-ware.

also /etc/ld.so.conf (which may contain "includes" like 
/etc/ld.so.conf.d/*.conf)

Have a nice weeked's reading! More inline below

rgrds
bruce

On 15/8/20 4:03 am, Brian G wrote:
> I am holding off on adding the /usr/bin directory as a possible source, it seems wrong to look for a library there.
See the FHS
> 
> I need some input here, I am thinking of having a directive for gambas scripts that prevent the usage of local libraries
> The reason I have for this is that it would be supper easy to simply hijack a script that is being used for production management with a local library which could be customized to do bad things if the script is being run with sudo privileges.
AFAIR, the security fraternity generally frowns upon having user home 
directories upon production systems. :-)
So, I wouldn't sweat on this one too much.
> 
> if my script used library x.0.0.0 from the system /usr/lib/gambas3
> and someone makes a local lib in ~/.local/share/lib/gambas3 called x.0.0.0
> 
Again beware of using literal paths for shared library paths. Depending 
on the actual filesystem on a system, and all the other things I have 
mentioned, they could be anywhere.
For example, on our internal shared development server, system shared 
libraries (so's) are located in /usr/local/lib64/xxx/ where xxx is either:
null i.e. it points to the server system libraries
"dev" or "base" or "staged" which are directories containing actual so's 
or links to other places in /usr/local/lib64. Gambas shared libraries 
are in /usr/local/lib64 or in one of those subdirs when we are working 
on "our" version(s) of native gambas components. Then there is "our" 
components (custom controls and the like) these are in further sets of 
subdirs. Hmm, that was about as transparent as a brick wall! Suffice to 
say tha if I was looking for a shared library based on "/usr/lib/" I 
wouldn't find it or a specific version of it. "/usr/lib/" is for distro 
installed shared libraries not locally installed libraries.

> they just hijacked my script and have su privileges!!!
Only on their PC. Unless they can write a gambas program to log in to 
the server with executive privileges, which means they have the root 
password already, which means they don't have to.

> 
> It can't be a command line option as that can be overridden... or if the script is executes directly...
No, well yes I don't think so.

> 
> I don't know if this would also affect gambas apps, but i think you define the exact lib in the ide to be used for apps.
If I understand you here, I don't think this is an issue. It is 
important to have an understanding that the world inside the IDE is 
different to that of the gbx3/gbr3 world.  For example, the IDE uses 
your gambas libraries to provide autocompletion, help and compilation 
but not execution. It is gbx3 that goes looking for the actual shared 
library at runtime to dynamically load and link to it. I don't know what 
gbs3 does.

----[ http://gambaswiki.org/wiki/doc/netiquette ]----

----[ http://gambaswiki.org/wiki/doc/netiquette ]----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbs3-3.15.90.tar.gz
Type: application/x-compressed-tar
Size: 42001 bytes
Desc: not available
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20200814/bc6c3396/attachment-0001.bin>