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 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\$ – Gilles 'SO- stop being evil' Aug 1 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 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\$ – Gilles 'SO- stop being evil' Aug 2 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 at 10:13

Python 3, 32 bytes

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

import os

Try it online!

| improve this answer | |
  • \$\begingroup\$ I'm not really sure how this works, but the code should be equivalent to print(1000!=os.getuid()). \$\endgroup\$ – ovs Jul 31 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 at 20:03
  • \$\begingroup\$ @Arnauld oof, just realized that. Stupid mistake on my part. \$\endgroup\$ – sugarfi Jul 31 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\$ – Gilles 'SO- stop being evil' Aug 1 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 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
| improve this answer | |
  • 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\$ – Peter Cordes Aug 1 at 4:48
  • 2
    \$\begingroup\$ I feel that trashing your system is an undesirable side-effect... \$\endgroup\$ – Neil Aug 1 at 6:43
  • \$\begingroup\$ @PeterCordes Indeed the privileges of /bin itself only allow root to create files there, changed. \$\endgroup\$ – Noodle9 Aug 1 at 10:22
  • \$\begingroup\$ @Neil It shows the great responsibility the comes with the power of root! T_T \$\endgroup\$ – Noodle9 Aug 1 at 10:24
  • \$\begingroup\$ You can remove /bin. \$\endgroup\$ – Gilles 'SO- stop being evil' Aug 1 at 10:31

Batch, 32 bytes

fltmc>nul&&echo True||echo False

Taken from this Stack Overflow answer.

| improve this answer | |
  • 1
    \$\begingroup\$ you can cut two bytes if you redirect to a single-letter file \$\endgroup\$ – peter ferrie Jul 31 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 at 23:32

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