There are two types of people in this world: users and admins. Let's find out who the real admins are.

The task is simple: If the script is run with elevation, print 'True' and only 'True' (only trailing newlines permitted as extra). If the script is run as an unelevated user, print 'False' and only 'False', exceptions granted for trailing new lines.

The code can be run on any operating system which is currently available free of charge, or on any CPU architecture as a code insertion OR it can run on Windows 10.

The selected operating system must have at least 3 privilege levels, and should return 'True' for any execution of code above the default user privilege level.

I couldn't find any tags for this, so please if you have suggestions, name them. Good luck!

  • 2
    \$\begingroup\$ Is this decision-problem (even though there's no input)? Would you consider relaxing the output requirements so that any two consistent truthy/falsy values are allowed? \$\endgroup\$
    – Dingus
    Aug 1 '20 at 2:13
  • 5
    \$\begingroup\$ Why the requirement for 3 privilege levels? That's pretty bizarre. Common operating systems only have two and the challenge requires a boolean result. All the existing answers check admin/non-admin without caring about some third level. \$\endgroup\$ Aug 1 '20 at 10:32
  • 3
    \$\begingroup\$ I feel like this question lacks a good definition of "privilege level". Two of the three current answers make specific assumptions about system configuration. And with things like capabilities and namespacing (under linux) the distinction what counts as "elevated" doesn't always seem easy. \$\endgroup\$
    – ManfP
    Aug 1 '20 at 11:19
  • 1
    \$\begingroup\$ @tuskiomi Unix without containers, capabilities or security frameworks. You're either root or you aren't. None of the existing answers account for anything beyond admin/non-admin, and would be wrong under any interpretation where the OS has more than 2 privilege levels. \$\endgroup\$ Aug 2 '20 at 9:44
  • 1
    \$\begingroup\$ @tuskiomi You are conflating x86's notion of "privileged" with the OS's. On all common consumer OSs, all user-mode code (including that of root/admin/...) will run as "unprivileged" user-mode, as far as x86 is concerned. It's only through syscalls to the kernel that a root-user process is able to access more resources. \$\endgroup\$
    – ManfP
    Aug 2 '20 at 10:13

Python 3, 32 bytes

-13 bytes thanks to @Arnauld -1 byte thanks to @Dingus

import os

Try it online!

  • \$\begingroup\$ I'm not really sure how this works, but the code should be equivalent to print(1000!=os.getuid()). \$\endgroup\$
    – ovs
    Jul 31 '20 at 20:02
  • \$\begingroup\$ @ovs I was about to ask the same thing. I think it's more like print(os.getuid()<1000), but I don't really speak Python. \$\endgroup\$
    – Arnauld
    Jul 31 '20 at 20:03
  • \$\begingroup\$ @Arnauld oof, just realized that. Stupid mistake on my part. \$\endgroup\$
    – sugarfi
    Jul 31 '20 at 20:10
  • 4
    \$\begingroup\$ Assuming this is meant for a unix-like platform, this is overly long and incorrect. 1000 is not a meaningful cutoff for privileges. User id 0 is privileged and others are not. \$\endgroup\$ Aug 1 '20 at 10:30
  • 1
    \$\begingroup\$ @sugarfl But "normal user" isn't the same as "unelevated user", it's more like "account intended for an actual human". A daemon can (and often will) run with even lower privileges than most users, and is not inherently privileged in any way. Only root (euid=0 in the root user namespace) is getting special ("privileged") treatment from the kernel, and that too keeps getting replaced by CAP_SYS_ADMIN etc. \$\endgroup\$
    – ManfP
    Aug 1 '20 at 17:37

Bash, 39 31 27 bytes

Saved 4 bytes thanks to Gilles 'SO- stop being evil'!!!

echo $a

Try it online!

Works on any *nix system.


a=False         # set env variable a to False
>/a             # try to create (>) (or overwrite if it exists) file /a 
                # but directory / has root write privileges 
                # and if /a is created by root in a
                # previous run the file will have root only 
                # write privileges
   &&a=True     # if this succeeds set a to True
                # if this fails a will be left as is   
echo $a         # will be True for root and False otherwise
  • 1
    \$\begingroup\$ Creating new files in /bin should also be disallowed for non-root, so you could use >/bin/9 or something that isn't an existing file on standard systems. Or >/9 should work; any sane system won't have unprivileged users able to create files in the root directory. On my Arch GNU/Linux system, /, /bin and /bin/[ have the same rwx-xr-x permissions, and no ACLs, so this fails for all non-root users. The question talks about systems with 3 permission levels; IDK if accounts like systemd-journal have more persmissions; just different. \$\endgroup\$ Aug 1 '20 at 4:48
  • 2
    \$\begingroup\$ I feel that trashing your system is an undesirable side-effect... \$\endgroup\$
    – Neil
    Aug 1 '20 at 6:43
  • \$\begingroup\$ @PeterCordes Indeed the privileges of /bin itself only allow root to create files there, changed. \$\endgroup\$
    – Noodle9
    Aug 1 '20 at 10:22
  • \$\begingroup\$ @Neil It shows the great responsibility the comes with the power of root! T_T \$\endgroup\$
    – Noodle9
    Aug 1 '20 at 10:24
  • \$\begingroup\$ You can remove /bin. \$\endgroup\$ Aug 1 '20 at 10:31

Batch, 32 bytes

fltmc>nul&&echo True||echo False

Taken from this Stack Overflow answer.

  • 1
    \$\begingroup\$ you can cut two bytes if you redirect to a single-letter file \$\endgroup\$ Jul 31 '20 at 23:00
  • 1
    \$\begingroup\$ @peterferrie Surely that will throw an error if you don't have the rights to create the file? For a question where rights are important, I wouldn't want to mess it up! \$\endgroup\$
    – Neil
    Jul 31 '20 at 23:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.