Page 1 of 1

About file path auto expansion in several library(os) predicates

Posted: Sun Feb 26, 2017 10:38 am
by dram
I found that there are several predicates in library(os) do file path expansion automatically (e.g. make_directory/1, delete_directory/1), which make me a bit surprised, for following reasons:

1. It is a bit uncommon, I can not immediately thought out some other languages which do the same.
2. It will make some task unable to to achieved (e.g. creating or deleting a directory named `$TERM`), although it is not quite a real use case.

Are there any reason behind?

Re: About file path auto expansion in several library(os) predicates

Posted: Sun Feb 26, 2017 11:21 pm
by Paulo Moura
Any sensible task that cannot be performed do to the implicit expansion? The expansion eventually happens in any system ...

Note that there is no Prolog standard (official or de facto) for operating-systems access. Worse, some Prolog systems don't even provide a uniform API across different operating-systems. Windows support in particular is incomplete and/or buggy in some systems. Expanding paths allow the POSIX representation used by Logtalk for paths to be properly converted when running on Windows overcoming issues with those systems.

Re: About file path auto expansion in several library(os) predicates

Posted: Mon Feb 27, 2017 2:04 am
by dram
If we take security into consideration, auto expansion is a bit vulnerable, similar to command injection[1], although not that serious.

Let me elaborate an example. If I use Logtalk to create a web application, using filesystem to store user data, one directory per user. If I naively use user name as directory name, I will have to validate user name carefully, or something like `$HOME`, `$PATH` will make data a mess.

I‘m not object to do file path auto expansion for Logtalk's own use case, but I think it is not suitable to be the default behaviour for a fundamental library.

[1] https://www.owasp.org/index.php/Command_Injection

Re: About file path auto expansion in several library(os) predicates

Posted: Mon Feb 27, 2017 10:43 am
by Paulo Moura
If you take security seriously, you validate all input data. Otherwise, you're already in trouble independently of what any library might do.

As I mentioned before, there are portability reasons to expand all paths. Another example: try to create a directory named '$EDITOR' (with the environment variable defined) using whatever native built-in or library predicate the Prolog systems provide. Some systems, e.g. CxProlog, JIProlog, SWI-Prolog or YAP, will create a '$EDITOR' sub-directory in the current working directory. GNU Prolog, ECliPSe, Lean Prolog, and SICStus Prolog expand the environment variable and create the sub-directory elsewhere (in /user/local/bin in my case). Thus, library expansion of paths before handing them to whatever native built-in or library predicate the Prolog systems provide is key to ensure portability.

If you still don't want path expansion to happen, then choose your backend Prolog compiler carefully and use its native file system predicates.

Re: About file path auto expansion in several library(os) predicates

Posted: Mon Feb 27, 2017 11:38 am
by dram
I see your point now, it's really a pity that such many Prolog implementations do path expansion.

I'll get used to it.

Thanks for your patience!