Bug 7488 - hard coded 0 for superuser's UID and GID
hard coded 0 for superuser's UID and GID
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
3.6.8
Other Other
: P3 enhancement
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-02 06:11 UTC by Joachim Schmitz
Modified: 2012-09-18 08:44 UTC (History)
0 users

See Also:


Attachments
Patch (17.45 KB, patch)
2010-06-02 06:12 UTC, Joachim Schmitz
no flags Details
SUPERUSER/SUPERGROUP patch (16.49 KB, patch)
2012-09-17 19:44 UTC, Joachim Schmitz
no flags Details
SUPERUSER/SUPERGROUP patch #2 (4.87 KB, patch)
2012-09-18 08:44 UTC, Joachim Schmitz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Schmitz 2010-06-02 06:11:44 UTC
There are quite a few places where Samba (and almost all other OpenSource projects) use a hardcoded 0 when checking UID (and GID) against being the superuser (or supergroup).
While this seems to be true for almost all systems Samba has been ported to, it is not true for the platform I'm trying to port it too, HP's NonStop Kernel (formerly an OS from Tandem Computers). Here the super user has the UID 65536 and the super group has the GID 255.
Weould we check against a macro (e.g. SUPERUSER and SUPERGROUP) and place tese in a central header files (like include.h, replace.h or config.h), we'd have the benefitm of a) making ports to wierd systems  easier and b) have more of a self documenting source, (e.g. "if (getuid() == SUPERSUSER)" rather than "if (!geuid())".

In the patch I'll attach, I picked ...source3/includes/includes.h as the above mentioned central header file. I had to add a "#include "include.h" in 2 places, and of course find and replace of those exlicit or implicit checks agains 0 with the macros.

Another patrt of the patch is to use "getpwnam(getlogin());" rather than "getpwuid(geteuid())"; in one place. I know that it is frowend upon in the UNIX world to have more than one username per UID, but this is very common pratice on NonStop Kernel (and consequently I've enabled it for that platform only via "#ifdef __TANDEM")

Bye, Jojo
Comment 1 Joachim Schmitz 2010-06-02 06:12:24 UTC
Created attachment 5757 [details]
Patch
Comment 2 Joachim Schmitz 2010-06-02 06:43:38 UTC
See also the old and long closed bug #585, and reconsider, 6 years later ;-)
Comment 3 Joachim Schmitz 2010-08-17 06:31:34 UTC
There's another small patch needed, for the configure step to work properly when detecting seteuid() and friends:

--- /usr/local/Floss/samba-3.5.4/source3/lib/util_sec.c.orig    2010-05-17 06:51:23.000000000 -0500
+++ /usr/local/Floss/samba-3.5.4/source3/lib/util_sec.c 2010-08-16 06:48:46.000000000 -0500
@@ -40,6 +40,8 @@
#define DEBUG(x, y) printf y
#define smb_panic(x) exit(1)
#define bool int
+#define SUPERUSER 0
+#define SUPERGROUP 0
#endif


Comment 4 Joachim Schmitz 2012-09-17 12:38:55 UTC
And change of moving this forward somehow?
Comment 5 Joachim Schmitz 2012-09-17 12:39:20 UTC
(In reply to comment #4)
> And change of moving this forward somehow?

"chance" ..
Comment 6 Jeremy Allison 2012-09-17 18:47:32 UTC
Sorry for the delay. Can you rebase your patch against master (things have changed somewhat here) and use SUPERUSER_UID and SUPERGROUP_GID instead of SUPERUSER and SUPERGROUP.

I'll take a look from there.

Jeremy.
Comment 7 Joachim Schmitz 2012-09-17 19:01:36 UTC
(In reply to comment #6)
Will do, but I'll be unable to test this, as I can't get master to build on my system.
Comment 8 Jeremy Allison 2012-09-17 19:03:14 UTC
That's a separate bug you should log :-). Thanks !
Jeremy.
Comment 9 Joachim Schmitz 2012-09-17 19:44:48 UTC
Created attachment 7899 [details]
SUPERUSER/SUPERGROUP patch
Comment 10 Joachim Schmitz 2012-09-17 19:47:12 UTC
(In reply to comment #9)
> Created attachment 7899 [details]
> SUPERUSER/SUPERGROUP patch

(In reply to comment #6)
> Sorry for the delay. Can you rebase your patch against master (things have
> changed somewhat here) and use SUPERUSER_UID and SUPERGROUP_GID instead of
> SUPERUSER and SUPERGROUP.
> I'll take a look from there.

There wo go. As mentioned entirely untested in this form, but in a similar for works since a long time for 3.[56].*
Can't guarantee that I found all spots that would need to get changed.
Comment 11 Joachim Schmitz 2012-09-18 08:44:05 UTC
Created attachment 7900 [details]
SUPERUSER/SUPERGROUP patch #2

I just found another few palces that need to get changed