stdlib/os: add isAdmin

[rominf]

Tested on Windows 10 as a normal user and as an administrator; on Fedora 33 as a normal user and as a root.

(EDIT(timotheecour))
fixes nim-lang/RFCs#329

[rominf]

@timotheecour I don't like printing isAdmin() result into the console; on the other hand, it tests that the code compiles and runs without exceptions...

[timotheecour]

@timotheecour I don't like printing isAdmin() result into the console; on the other hand, it tests that the code compiles and runs without exceptions...

i think this was already addressed by:

  let isAzure = existsEnv("TF_BUILD") # xxx factor with testament.specs.isAzure
  if isAzure: doAssert isAdmin()

but in other situations, instead of echo you can use:

discard someAPI() # no warning unused

for that, or even:

let ok = someAPI() # not as good, would issue a warning

[Varriount]

What would a "classic use case" of this function be?

[rominf]

What would a "classic use case" of this function be?

See: nim-lang/RFCs#329 (checking symlinks creation on Windows)

[Varriount]

What would a "classic use case" of this function be?

See: nim-lang/RFCs#329 (checking symlinks creation on Windows)

Being root or Administrator shouldn't be conflated with having the ability to do something. It's quite possible to allow users other than the Administrator to create symlinks on Windows.

I don't think that this function should be added, precisely because of this misconception. There are relatively few situations where one actually needs to know whether the user is root/administrator. Usually, one should assume that the user has permission to do something, and appropriately handle the cases where permission is denied.

[rominf]

Thanks, @timotheecour, and @Araq for pointing me at my mistakes and for your patience!

I've been busy these days and finally got some time to fix the code.

[Varriount]

While I appreciate the improvements made, I would still like to know: what use-cases does this addition address? Especially given the fact that it can be easily misused.

[Araq]

Sorry, but this code should go into its own module. Suggestion: extensions / admin. Yes, this "extensions" directory would be new, no, it won't move to std. Yes, I am changing my mind, we need more than just std.

[timotheecour]

Sorry, but this code should go into its own module. Suggestion: extensions / admin. Yes, this "extensions" directory would be new, no, it won't move to std. Yes, I am changing my mind, we need more than just std.

I'm fine (and in fact in favor) of a separate module (modules are cheap, giant modules like times and os should be broken down and re-export their sub-modules, even if we implement cyclic imports), however:

• this module should be importable from std/os without introducing cyclic dependencies in case it's needed there (eg use cases: better error messages, plausible approach for copyDir semantics for syminks on windows, along with Add isWindowsDeveloperModeActive RFCs#343 etc)
• extensions/ at the root needs an RFC, and in fact it sounds very similar to Fusion and stdlib evolution RFCs#310 which wasn't popular; in any case stdx would be much better IMO

In the meantime, we can move this to a new module lib/std/private/osutils and "decide later", at least the implementation will be there and could be used within the confines of nim repo (plus whoever is ok with breaking changes) and doesn't have to wait on deciding on stdx vs extensions vs os

[timotheecour]

ok for now, but we should address nim-lang/RFCs#344 before next release and move it to wintypes

[timotheecour]

finished review; after comments are addressed we can decide what to do with #17012 (comment) (keep in os, move to std/private/osutils, other)

[rominf]

While I appreciate the improvements made, I would still like to know: what use-cases does this addition address? Especially given the fact that it can be easily misused.

For example, some installation scripts that write into /usr, /etc or C:\Program files, start daemons/services usually check admin rights before execution.

[rominf]

@timotheecour Comments are addressed.

[timotheecour]

LGTM.
for #17012 (comment), IMO extensions / admin isn't warranted, because it's conceivable isAdmin can be useful for procs in std/os. That said, I'd support splitting std/os in future work into multiple submodules that would be imported and re-exported by std/os (can be done transparently); modules are cheap.