Hacker News Reader

Comment by usr1106 | Hacker News Reader

I like slim Linux machines and I several times considered to remove or at least disable accountservice. I has never been clear to me why you need such service as long as /etc/passwd is world readable. So from this article I learn

* calling mount during installation(?) when there is no user. Makes no sense to have the daemon running later

* providing a user icon. Exactly the type of functionality I like to throw out

* providing a user specific language setting. I can see that this is useful for some users

So how is dropping privileges done correctly to avoid getting killed by the user? Running as another user is one way, but I guess that is not always feasible if you want the daemon provide services for the user. On the other hand accountservice is there for multiple (human) users. So as which of them is it running? Not at a machine right now...

View on HN

> So how is dropping privileges done correctly to avoid getting killed by the user?

I think you got the wrong idea from the article, which is partly author's fault. He claims user should not be able to do that, but that is a highly anti-user anti-unix viewpoint.

Creating a destroying (crashing) processes running with uid of any non-root user is something like an obvious inalienable right of that unix user. It is expected that this works.

The problem to solve is that the crash of the user daemon confuses gdm (a root process) which then behaves as if the computer is in the installation phase and the user is to be trusted with setting up high-privilege account.

The solution for Ubuntu is obvious, fix gdm. For administrators / power users, use something simpler such as xdm, where these kinds of errors are unlikely to occur.

> So how is dropping privileges done correctly to avoid getting killed by the user?

I was wondering this too. What is the way to "correctly" drop privileges? Is it even possible to drop privileges within a process in a way that's immune to this?

I guess you could fork first?

Fork then handle child/exec error codes appropriately.

Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child.

Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.

Forking does not affect the possibility to receive signals, does it?

logged in into one of my machines via ssh. The daemon is running with all uids being 0 and full capabilities. Don't see how that would be dropping any privileges. On the other hand

* The machine has no desktop user at the moment

* The program was patched on 04-Nov, I guess addressing this issue.

The program only temporarily drops privileges while reading the user-supplied file. The rest of the time, it would have all uids as 0 and full capabilities.

Drop them in a subprocess, read the file and send the data to the parent?

There is no “tried and true” method to drop privileges after you’re done with them; this has been a constant source of headaches and security issues for pretty much any app that needs to be started as root in order to xxx (eg bind to a low port, if we pretend that’s the only way) and then drop said privileges.

The solution is almost always to use (or add) kernel constructs that would obviate the need to elevate in the first place, but they generally aren’t fine-grained enough so on paper it looks like dropping privileges makes more sense, though in practice it might turn out to be the bigger mistake.

The more or less default way how to accomplish this (ie. setuid(1)) is immune to that issue. On the other hand it does not really drop privileges in the modern sense as the process can regain them at any time because it is still owned by root.

No, a privileged process can't regain privileges after setuid(2).

seteuid(uid) if you want to revert later.

> So how is dropping privileges done correctly to avoid getting killed by the user?

For this case of temporarily lowering access rights to avoid user loading unauthorized files, by only setting effective user id (EUID) (or filesystem user id (FSUID), though its use should be avoided nowadays) instead of real user id (RUID) like the code did. And same for group id.

> I has never been clear to me why you need such service as long as /etc/passwd is world readable.

And you access that using the POSIX getpwent(3) family of functions, which glibc wraps to honor nsswitch.conf. accountservice seems superfluous.

On Linux, set your fsuid instead. And do it in a subprocess you can kill to avoid the DoS.

Agreed. Why would you need to run a daemon for the latter two points? These requirements can just as easily be handled by storing files in a fixed location in the user’s home directory.

Reply on news.ycombinator.com