Read-only pseudo devices

[infradig]

There is no read-only pseudo-device. It seems /dev/urandom & /dev/zero etc can be written to, it is not an error, so the latest tests added to library/os on this subject cannot be made to succeed.

[pmoura]

While noting that the new os::read_only_device_path/1 predicate is labeled as experimental, CxProlog, JIProlog, LVM, Scryer Prolog, SICStus Prolog, SWI-Prolog, Trealla Prolog, and XSB pass the two tests (at least on macOS, my main testing environment). ECLiPSE fails the second test simply because while it throws an exception, as expected, but not a standard error/2 exception term. Tau Prolog doesn't handle the write permission error that it gets from node:internal/fs/utils properly and crashes. As an equivalent to /dev/urandom is not available on Windows systems, the tests are skipped in that case.

P.S. The reason why /dev/urandom is a read-only device is due to the security implications of being able to write to this device.

[infradig]

The second one doesn't on Ubuntu (and I expect all Linux). Note the behaviour on writing to those devices is undefined.

On Sat, Aug 5, 2023 at 3:34 PM Paulo Moura @.***> wrote:

While noting that the new os::read_only_device_path/1 predicate is labeled as experimental, CxProlog, JIProlog, LVM, Scryer Prolog, SICStus Prolog, SWI-Prolog, Trealla Prolog, and XSB pass the two tests (at least on macOS, my main testing environment). ECLiPSE fails the second test simply because it throws an exception, as expected, but not a standard error/2 exception term. As an equivalent to /dev/urandom is not available on Windows systems, the tests are skipped in that case.

— Reply to this email directly, view it on GitHub https://github.com/LogtalkDotOrg/logtalk3/issues/181#issuecomment-1666398157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEQPTNKGFZYQH7JG42LXTXLN3ANCNFSM6AAAAAA3EYXY6E . You are receiving this because you authored the thread.Message ID: @.***>

[infradig]

All of cx, b, ciao, scryer, xsb, gnu, swi, eclipse & trealla (that's all I have) fail on Ubuntu.

On Sat, Aug 5, 2023 at 3:34 PM Paulo Moura @.***> wrote:

While noting that the new os::read_only_device_path/1 predicate is labeled as experimental, CxProlog, JIProlog, LVM, Scryer Prolog, SICStus Prolog, SWI-Prolog, Trealla Prolog, and XSB pass the two tests (at least on macOS, my main testing environment). ECLiPSE fails the second test simply because it throws an exception, as expected, but not a standard error/2 exception term. As an equivalent to /dev/urandom is not available on Windows systems, the tests are skipped in that case.

— Reply to this email directly, view it on GitHub https://github.com/LogtalkDotOrg/logtalk3/issues/181#issuecomment-1666398157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEQPTNKGFZYQH7JG42LXTXLN3ANCNFSM6AAAAAA3EYXY6E . You are receiving this because you authored the thread.Message ID: @.***>

[pmoura]

We did noticed the second test failing for LVM in a Ubuntu pipeline. But I'm yet to test others there. Thanks for reporting. Linux behavior here is puzzling and unfortunate. Wondering about BSD systems as some of them have a strong reputation for security. I may have to further reduce the systems where the tests are not skipped.

[pmoura]

From https://linux.die.net/man/4/urandom

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

I have not found definitive information so far on BSD systems. But I'm going to assume that they behave here the same as Linux systems. I changed the tests to only run on macOS systems. Pity. A more universal read-only device would be great when testing stream I/O features.