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
Created attachment 5757 [details] Patch
See also the old and long closed bug #585, and reconsider, 6 years later ;-)
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
And change of moving this forward somehow?
(In reply to comment #4) > And change of moving this forward somehow? "chance" ..
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.
(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.
That's a separate bug you should log :-). Thanks ! Jeremy.
Created attachment 7899 [details] SUPERUSER/SUPERGROUP patch
(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.
Created attachment 7900 [details] SUPERUSER/SUPERGROUP patch #2 I just found another few palces that need to get changed