Project

General

Profile

Bug #1352

setuid/setuid called without checking result code

Added by Benny Lyne Amorsen - almost 8 years ago. Updated almost 8 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
General
Target version:
Start date:
2012-10-22
Due date:
% Done:

0%

Estimated time:
Found in version:
v3.3-77-g72d90ee
Affected Versions:

Description

In main.c, setuid() and setgid() are called, but the result code is thrown away. This could lead to Tvheadend running with unexpected privileges.

Fedora is now compiling by default with -Werror=unused-result which prevents compilation of Tvheadend, but that can be turned off easily. If I read git blame correctly, the problem existed in the first version checked into git.

Associated revisions

Revision a3a917cc (diff)
Added by Adam Sutton almost 8 years ago

Ref #1352 - check return value of setuid/setgid calls.

Also slightly changed the logic so its possible to fork as non-root, though
you must explicitly list your username and group with -u and -g as I do not
want to break built in defaults for compatibility.

Revision 74e73a98 (diff)
Added by Adam Sutton almost 8 years ago

Fix #1352 - check return value of setuid/setgid calls.

Also slightly changed the logic so its possible to fork as non-root, though
you must explicitly list your username and group with -u and -g as I do not
want to break built in defaults for compatibility.
(cherry picked from commit a3a917cc2947822abd09f57bbabe4620f2b4271c)

History

#1

Updated by Adam Sutton almost 8 years ago

  • Status changed from New to Accepted
  • Assignee deleted (Hein Rigolo)
  • Target version deleted (3.3)

This must be something different in newer version of GCC, since I don't get any such problems with the version on my dev machine (gcc 4.6.3). Or possibly some variation in the func attributes set in libc, etc...

We already compile, by default, with -Wall and -Werror, which would cover the above option.

I guess the question would be what should happen if it fails to correctly set the user/group. This can pretty much only happen if the user starting TVH is not root, since a bad user/group spec will default to daemon:daemon (which should always succeed).

We could silently fail (user would only know the reason if they check syslog) or we could just log the error and continue.

#2

Updated by Adam Sutton almost 8 years ago

  • Target version set to 3.2

This should be a relatively simple fix, once we decide what the appropriate action should be.

Once it is fixed I think it makes sense to back port this to 3.2.

#3

Updated by Adam Sutton almost 8 years ago

  • Affected Versions 3.2 added
#4

Updated by Adam Sutton almost 8 years ago

  • Status changed from Accepted to Fixed
  • Target version changed from 3.2 to 3.4
  • Affected Versions 3.3 added

This should now be sorted by a3a917cc2947822abd09f57bbabe4620f2b4271c. If you could check this I would appreciate that.

Adam

#5

Updated by Benny Lyne Amorsen - almost 8 years ago

It works! It compiles and runs.

#6

Updated by Adam Sutton almost 8 years ago

  • Target version changed from 3.4 to 3.2

Also available in: Atom PDF