Specs failing when run as superuser

[straight-shoota]

Some specs in the std_spec fail when running as superuser. They expect some operations to be forbidden, which only applies unprivileged users.
This is problematic because in some environments (for example our docker images), the default user is root.

For example, running make std_spec in a crystallang/crystal docker container results in two specs failing:

  1) Process .chroot raises when unprivileged
     Failure/Error: {% if flag?(:unix) && !flag?(:android) %}

       Expected: "#<RuntimeError:Failed to chroot: Operation not permitted>\n"
            got: "FAIL\n"

     # spec/std/process_spec.cr:428

  2) File raises when reading a file with no permission
     Failure/Error: expect_raises(File::AccessDeniedError) { File.read(path) }

       Expected File::AccessDeniedError but nothing was raised

     # spec/std/file_spec.cr:871

These specs should either be disabled when run as superuser, or ideally modified to work regardless of the superuser status.

• process_spec.cr:428 tests that Process.chmod fails with the correct error message when the executing user is not root. It runs a new process, so it could theoretically execute that process as a non-root user. This requires the existence of a non-root user, though.
• file_spec.cr:871 tests that a file with file mode 0 is unreadable. Apparently this isn't true for the superuser. I don't see any other solution to run this test except for dropping root.

It seems like both these specs require the existence of a non-root user, which isn't necessarily the case and would just be another reliance on the execution environment as being run as unprivileged user.
So maybe the best solution would be to skip these tests when the executing user is root.

[jhass]

As for dropping permissions, shouldn't the nobody user be available as an unprivileged user in pretty much any (unix) environment?

[straight-shoota]

Good point. Actually, it seems set*uid doesn't even require the uid to "exist" on the system in the form of an entry in /etc/passwd. So basically, any uid should work, as long as it's not 0.

This diff makes the chmod spec succeed (note there's no user with id 12345 in the crystal image).

--- a/spec/std/process_spec.cr
+++ b/spec/std/process_spec.cr
@@ -428,6 +428,12 @@ describe Process do
     {% if flag?(:unix) && !flag?(:android) %}
       it "raises when unprivileged" do
         status, output, _ = compile_and_run_source <<-'CRYSTAL'
+          lib LibC
+            fun setuid(uid : UidT) : Int
+          end
+          # drop privileges to nobody user
+          LibC.setuid(12345)

[straight-shoota]

With #13226 and #13227 merged, the stdlib spec suite not succeeds when run as superuser.