The Linux ether-wake utility, which creates a magic packet to wake on lan another machine, requires root access:

$ether-wake 12:34:56:78:9A:BC
ether-wake: This program must be run as root.

To give access to an arbitrary user would require either making it SUID root, or adding /sbin/ether-wake to /etc/sudoers.

My concern is that ether-wake must require root for a reason, so does that mean that it isn't safe to allow ordinary users access to this command?

What detrimental effects on our network could result from giving users access to this command?


Note that magic packets work regardless of their type. Your tool requires root because it sends Ethernet frames directly. However, there is nothing stopping someone from sending the same data inside UDPv4 broadcasts, which is in fact done by practically all other wake-on-LAN tools. (UDP port 9 is common.)

This makes network security concerns mentioned in other answers more-or-less irrelevant.

  • Exactly, or a user can connect his laptop to the LAN cord. Security should be elsewhere than in the client stations.
    – user49760
    Nov 15 '14 at 17:08

That utility needs root access because it uses a raw ethernet socket. In a similar way, ping needs root access, as it also uses raw sockets. The difference is that (on most systems) ping is suid-root so any user can run it.

If you're happy with non-root users generating these packets, you can make etherwake suid-root, or use sudo as you suggested. There is a small technical risk, in that etherwake may have privilege escalation vulnerabilities, but given that the program is quite simple, I'd find that risk acceptable.

  • 7
    If your system supports it, you can grant just the required capability, CAP_NET_RAW: setcap cap_net_raw+ep /usr/local/bin/ether-wake. This would reduce the exposure in case of a privilege escalation vulnerability. Nov 11 '14 at 15:39
  • 5
    CAP_NET_RAW is a subset of CAP_SYS_ADMIN (root), so it's certainly no more a security concern than granting root.
    – David
    Nov 11 '14 at 16:17

The act of powering down or powering up a machine should be restricted to a small subset of administrators and security personnel in your organization. The act of remotely sending a Wake on Lan packet could have serious negative security and administrative implications if it is given to the wrong users.

If you are worried about adding a user to the sudoers list, as a principle, they should not be running commands that require root access.

A negative scenario for you:

  1. There are several machines on your network that have been powered down due to a virus infection. They are slated to be cleaned, but have not been cleaned yet. Someone in the networking department notices the machines are down and uses their new shiny "ether-wake" tool to start the machine, not knowing that it is infected.

As a rule of thumb, you don't want to give EVERYONE access the power to turn on almost device in your network. It's a really bad operations, security, and networking idea.

  • 6
    If you wanted to isolate infected machines, wouldn't you just manage this at the network level, shifting them into an isolated network by MAC address, rather than powering them down? Just powering them down wouldn't stop the user pressing the power button on the machine when they got to their desk. Anyway, it sounds like the way to go is to create a database of who is allowed to power on what, and run ether-wake from a wrapper script which only allows a user to remote power up machines that they have personal responsibility for. This would give you the benefits, while mitigating the risks.
    – Mark Booth
    Nov 11 '14 at 14:50
  • Yes, isolating machines on a network level would make sense, but I just wanted to play devil's advocate and describe a poorly managed situation. Nov 11 '14 at 14:59
  • 6
    Anyone can sent the packet, just by plugging their own machine into your network! Nov 11 '14 at 16:35
  • Right, that's why you need to have a good NAC (Network Access Control) setup as well as restricting physical access to ethernet jacks. Nov 11 '14 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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