I wonder that an SUID program like passwd is using the setuid() function call. Why does it drop root privileges?

Against what types of attack does this help? Buffer-overflow?

  • 1
    I don't think passwd does call setuid() to drop privileges, but it does have the setuid bit set so that it will escalate privileges when executed. At least, that is the important thing to understand about passwd in this regard.
    – goldilocks
    Feb 16, 2013 at 12:32

2 Answers 2


First I'll discuss the setuid bit, which passwd uses and is distinct from the setuid() system call (which passwd does not use). There is perhaps some confusion in the question in this regard.

It is not a protection against a buffer overflow, it's vunerable to such, or basically anything which would allow an attacker to use a privileged process for some nefarious unintended purpose. This is because the setuid bit is the opposite of "dropping privileges"; it bestows root privileges, but only to the process and not the actual user. That includes passwd.

That form of setuid requires the filesystem setuid bit set on the executable; passwd has this because it needs privileges to read and write /etc/passwd. However, we hope passwd does not have any known security vulnerabilities (eg, potential overflow exploit) that would allow a nefarious person to get it do something other than reading and writing /etc/passwd (and other than doing that properly!), since it does run as root, and therefore could do anything -- except it is designed to do only one specific thing, and getting it to do anything else should (again, hopefully) be impossible.

So using setuid in that sense is not protection against anything, but it is often discussed in relation to vulnerabilities because potential vunerabilities are very important WRT setuid executables.

BUT: the setuid bit sets the euid and not the actual uid, so it is actually parallel to the seteuid() system call and not setuid().

There is an opposite form of "setuid" that is about dropping privileges, which involves the actual setuid() system call and does not require the setuid bit. This is when a process running as root (because root or sudo started it) changes its uid to a less privileged user. Servers and daemons often do this if they need root privileges at start up (eg, to open a privileged port) but not subsequently. That way if the server subsequently gets jacked, it does not have superuser privileges. You cannot call setuid(0) and get root privileges back (but you can with set*e*uid).

  • thank you, the last paragraph is the most valuable for me, but the explanation is very good, thank you
    – flatronka
    Feb 17, 2013 at 9:51
  • You deserve more upvotes for this great answer.
    – hitchhiker
    Jan 4, 2017 at 19:29

It's simply a preventative measure. Any app could potentially be vulnerable to any exploit conceivable if miscoded. The trick to reducing the possible damage is to perform actions with the least privileges required. Dropping running as root when not needed is an excellent start.


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.