[Gambas-user] Test Module, First try

Bruce adamnt42 at gmail.com
Fri Aug 14 22:36:36 CEST 2020


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.


More information about the User mailing list