love.filesystem.isDirectory in higher levels

[G.o.D]

Hi,

i have a problem with love.filesystem.isDirectory, i want to scan a directory with love.filesystem.enumerate that is higher then my game directory

if i enumerate(""), isDirectory works, if i enumerate("mysubdirectory") it works too, but if i enumerate("../somediroutside") it always delivers false.

Is this a bug or am i doing something wrong?

Thanx in Advance,

[Boolsheet]

It is intentional. The love.filesystem module can only access the save and game directory (or game archive).

[G.o.D]

well, it does read the directory, you can list its contents, it just fails to figure out if the read entry is a directory, i am not sure how this could be intentional

[Boolsheet]

Maybe I confused something with SELÖVE.
I was under the impression that you're not supposed to leave the save/game directory. (And it's a hidden feature if a function allows it, not a bug )

Perhaps one of the developers can state where exactly the limits of the filesystem module should be.

[TechnoCat]

Maybe I confused something with SELÖVE.
I was under the impression that you're not supposed to leave the save/game directory. (And it's a hidden feature if a function allows it, not a bug )

Perhaps one of the developers can state where exactly the limits of the filesystem module should be.

You cannot write outside the save directory with love.filesystem functions, you also cannot read outside the LOVE or the save directory.

None of these stipulations apply to the Lua io module. You can eliminate or read all our (save SELove users) files with Lua io if you wanted to .

[G.o.D]

so it is actually a bug in love.filesystem.enumerate? as it can read outside love and save directory?

Anyway, this is a stupid restriction, if you can use lua io anyway, it doesnt really restrict the programmer from doing bad things if he really wants to - and actually its the job of the operating system to provide security, not of the development environment.

It seems scanning directories is not a standard feature of lua, but there are lua developed libraries out there that provide that feature, so again, i can totally do this in love, just not with the functions love provides (or as enumerate can, i can, but just not with all)... useless and confusing restriction

[tentus]

Anyway, this is a stupid restriction, if you can use lua io anyway, it doesnt really restrict the programmer from doing bad things if he really wants to - and actually its the job of the operating system to provide security, not of the development environment.

Everybody duck, I can hear Robin loading his catapults now...

[Robin]

so it is actually a bug in love.filesystem.enumerate? as it can read outside love and save directory?

It is a bug that you can read outside of the write directory, yes.

Anyway, this is a stupid restriction, if you can use lua io anyway,

Not in SELÖVE you can't, and with good reason. While LÖVE malware is pretty rare right now, it does exist, and with our forumwide habit of downloading and running every .love we come across, that's a pretty big security hazard.

but there are lua developed libraries out there that provide that feature,

I doubt you can use them without hurting crossplatformness.

[slime]

While LÖVE malware is pretty rare right now, it does exist, and with our forumwide habit of downloading and running every .love we come across, that's a pretty big security hazard.

If you're concerned about malware hidden in a program, then the "security hazard" of allowing love.filesystem real access to the filesystem is much much less than the fact that you can download anything you want from the internet with luasocket and run terminal commands with os.execute/io.popen. There's no reason to restrict a useful feature because you're scared of something that will happen regardless of whether the feature is there or not.

but there are lua developed libraries out there that provide that feature,

I doubt you can use them without hurting crossplatformness.

I believe PhysFS (which is what LÖVE uses) is designed to be crossplatform, so it would be ideal for this.

[Robin]

If you're concerned about malware hidden in a program, then the "security hazard" of allowing love.filesystem real access to the filesystem is much much less than the fact that you can download anything you want from the internet with luasocket and run terminal commands with os.execute/io.popen.

That's why SELÖVE disables os.execute and io.popen as well. Luasocket is not a problem on itself.

There's no reason to restrict a useful feature because you're scared of something that will happen regardless of whether the feature is there or not.

What is useful is debatable. And as for "something that will happen": SELÖVE is as far as I know completely secure in it's current state. (With much thanks to bartbes.)

I believe PhysFS (which is what LÖVE uses) is designed to be crossplatform, so it would be ideal for this.

Yes, so it would be foolish to use a third party library to try to replace it.