4 ms·

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 a

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...

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
mehrdadn 6y ago
> 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?
- jontro 6y ago
  I guess you could fork first?
  - jasonjayr 6y ago
    Fork then handle child/exec error codes appropriately.
    - usr1106 6y ago
      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.
  - usr1106 6y ago
    Forking does not affect the possibility to receive signals, does it?
- usr1106 6y ago
  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.
  - mnw21cam 6y ago
    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.
- skykooler 6y ago
  Drop them in a subprocess, read the file and send the data to the parent?
- ComputerGuru 6y ago
  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.
- dfox 6y ago
  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.
  - jwilk 6y ago
    No, a privileged process can't regain privileges after setuid(2).
- GoblinSlayer 6y ago
  seteuid(uid) if you want to revert later.
amluto 6y ago
On Linux, set your fsuid instead. And do it in a subprocess you can kill to avoid the DoS.
effie 6y ago
> 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.
blux 6y ago
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.
thwarted 6y ago
> 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.
AnssiH 6y ago
> 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.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

mehrdadn 6y ago

> 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?

jontro 6y ago
I guess you could fork first?
- jasonjayr 6y ago
  Fork then handle child/exec error codes appropriately.
  - usr1106 6y ago
    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.
- usr1106 6y ago
  Forking does not affect the possibility to receive signals, does it?
usr1106 6y ago
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.
- mnw21cam 6y ago
  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.
skykooler 6y ago
Drop them in a subprocess, read the file and send the data to the parent?
ComputerGuru 6y ago
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.
dfox 6y ago
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.
- jwilk 6y ago
  No, a privileged process can't regain privileges after setuid(2).
GoblinSlayer 6y ago
seteuid(uid) if you want to revert later.

amluto 6y ago

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

effie 6y ago

> 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.

blux 6y ago

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.

thwarted 6y ago

> 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.

AnssiH 6y ago

> 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.