sync is one of the user account created by Debian itself. I'm wondering why Debian sets its login shell to /bin/sync instead of /bin/false. How does Debian use this user account?
1 Answers
This is documented in /usr/share/doc/base-passwd/users-and-groups.txt.gz:
sync
The shell of user
syncis/bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system.
This is really a historical artifact, I wouldn't expect a sync user to be set up in this way nowadays. In the past it would be useful to have such a user so that people with physical access to a console (e.g. in a server room or a lab full of workstations, as you'd find in universities) could reduce the risk of data loss when shutting down a system (to recover from a rogue process or simply to use the workstation, if it had been left locked by its previous user). Unix systems before Debian tended to have a sync user and a shutdown user with which you could actually shut a system down properly without knowing the root password. (On our Sun SPARCstations we'd just STOPA boot...)
It's worth noting, as Peter Cordes mentioned, that other mechanisms are available on many systems to ensure safe shutdowns or reboots from a console without being able to authenticate as root: ACPI events triggered by pressing the power switch (which lead to a clean shutdown), or CtrlAltDel (which leads to a clean reboot). AltSysRq can be used as a last resort to sync, kill, unmount and reboot, but it's not a clean reboot. As mentioned by JdeBP, having a sync user is a very old idea, dating back at least to the early 1980s.
- 411,918
- 54
- 1,065
- 1,164
-
I'm confused. So users are expected to set its password to something easy to guess so that anyone can sync the system even if they have no account? – Cyker Dec 05 '16 at 14:03
-
4Users aren't expected to do anything. Admins are able to set the system up in this way, if they want to. The historical context is relevant here: back when the `sync` user was added, the Alt+SysRq combos didn't exist, and a Linux system was more likely to be a server somewhere or a shared system in a lab, than a single-user laptop or desktop. It was useful to provide a way people with access to the console could safely prepare a system for an unclean shutdown, so they could reboot systems without having root access while reducing the risk of data loss. – Stephen Kitt Dec 05 '16 at 14:10
-
I confirm. It was a standard _"user"_, before Debian was created. So it is just an historical left over. Now _sync_ like function is (usually) run more frequently, so no more need to run it manually. – Giacomo Catenazzi Dec 05 '16 at 14:24
-
2Worth pointing out that instead of having a `shutdown` account, default installs of some (many?) Linux distros are set up such that ctrl+alt+f1 (to get to a text console in case the current VT is running a graphical login screen) followed by ctrl+alt+del triggers a `shutdown -r now` or equivalent. So physical access = ability to trigger a clean reboot, even without SysRQ. – Peter Cordes Dec 05 '16 at 17:05
-
1@PeterCordes note "Unix systems before Debian" — this is pre-1993 ;-). But yes, on current systems there are often other ways of doing things without using `sync` or `shutdown` users. (To be extra-nit-picky, many Linux distros have the DM on VT1 nowadays. Some don't even have any text VTs any more!) – Stephen Kitt Dec 05 '16 at 17:11
-
1back when the `sync` user was added ... Linux as an idea didn't exist. This convention goes back to the early 1980s, at least. – JdeBP Dec 05 '16 at 17:12
-
@JdeBP I was actually referring to "when the `sync` user was added in Debian" (in the context of the question), but yes, you're absolutely right. – Stephen Kitt Dec 05 '16 at 17:15
-
My point was that Debian (and other distros) do still implement the same physical access = clean reboot / shutdown paradigm out of the box, just with a different mechanism. Depending on how the ACPI power button is configured, it may trigger `shutdown -h`, otherwise you can just wait for the system to finish shutting down and trigger a reset (which flashes the lights and seeks the drives in a pretty recognizable way) to achieve the same thing before yanking the power. – Peter Cordes Dec 05 '16 at 17:43
-
@GiacomoCatenazzi _"Now sync like function is (usually) run more frequently ..."_ - [citation needed] – marcelm Dec 05 '16 at 17:43
-
2You have to remember some of these systems are from a time before "personal" computers. As such a sync could be to tape or some other horridly slow running media, like token ring, floppies. At the same time these systems were "fragile" enough that a power cycle could damage them. So if your UPS says 5 mins till outage, you shutdown, and skip syncing, lest you ruin a multi-million dollar machine. These issues largely don't exist anymore. – coteyr Dec 05 '16 at 20:36
-
@coteyr Citation needed that any ancient Unix stored its filesystem on tape or token ring networks. They might have had both those devices, but probably not in a path where `sync` could affect them. – poolie Dec 05 '16 at 22:26
-
@PeterCordes Alt-SysRq `s` will flush all data and `u` will unmount (actually remount r/o) all filesystems, so shutdown will then be clean. – poolie Dec 05 '16 at 22:28
-
1@poolie: it doesn't run any shutdown scripts. If you did this on a busy server, there would be half-written files and so on. Even non-journaled filesystems would probably be consistent, but the data on them would be a snapshot of the current state when you hit alt+sysrq+u. Processes like SQL servers do their own journaling so they'd be able to recover, but they would see a non-empty journal (unlike if you'd done a clean shutdown that sent a SIGTERM to running processes, so they'd exit cleanly). – Peter Cordes Dec 05 '16 at 23:37
-
@PeterCordes You can use `Alt SysRq e` to send those processes a SIGTERM before you unmount. Yes, if you have very complicated shutdown rituals you can't do them, but ugh, that's just asking for trouble. – poolie Dec 07 '16 at 00:15
-
@poolie: Recent Ubuntu installs only enable `s`, `u`, and `b` by default, not any of the other sysrq commands. (sysctl `kernel.sysrq = 176`). Being robust enough for this to not be a problem is extremely desirable, and good point that sysrq+e would be a good one to start with; maybe I should enable that, too. OTOH, I usually only use sysrq to reboot when something has gone horribly wrong, and depending on what that is, writing out more data in memory might actually do more harm than good. Anyway, it's a good fallback if you can't get ctrl+alt+del to work, but it's not technically "clean". – Peter Cordes Dec 07 '16 at 02:47