From: Junio C Hamano <hidden> Date: 2016-06-15 22:49:47
Erik Faye-Lund [off-list ref] writes:
quoted
quoted
-static int serve(struct string_list *listen_addr, int listen_port, struct passwd *pass, gid_t gid)
+#ifndef NO_POSIX_GOODIES
+static struct passwd *pass;
+static gid_t gid;
+#endif
+
+static int serve(struct string_list *listen_addr, int listen_port)
{
struct socketlist socklist = { NULL, 0, 0 };
This is ugly. Why did you need to make the arguments file-scope static?
To avoid having different signatures for the serve-function dependent
on NO_POSIX_GOODIES.
Why does the signature even have to be different between the two to begin
with? I _think_ you have gid_t over there, although you might not have
"struct passwd", in which case you can just define an empty one that your
alternate implementation is not going to use anyway. This is especially
true if you are making the "drop-privileges" part a helper function, no?
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:49:48
On Fri, Oct 15, 2010 at 11:16 PM, Junio C Hamano [off-list ref] wrote:
Erik Faye-Lund [off-list ref] writes:
quoted
quoted
quoted
-static int serve(struct string_list *listen_addr, int listen_port, struct passwd *pass, gid_t gid)
+#ifndef NO_POSIX_GOODIES
+static struct passwd *pass;
+static gid_t gid;
+#endif
+
+static int serve(struct string_list *listen_addr, int listen_port)
{
struct socketlist socklist = { NULL, 0, 0 };
This is ugly. Why did you need to make the arguments file-scope static?
To avoid having different signatures for the serve-function dependent
on NO_POSIX_GOODIES.
Why does the signature even have to be different between the two to begin
with? I _think_ you have gid_t over there
We don't, so this is the primary reason. But also avoiding
compilation-warnings is a secondary motivation.
although you might not have
"struct passwd", in which case you can just define an empty one that your
alternate implementation is not going to use anyway.
We do, so this becomes a bit of a hypothetical question. But would you
seriously consider pretending to have a posix-feature less ugly than
inlining a function that is only used once?
(I'm going a little off-topic here, I hope that's OK)
I'm not too happy with some of the
pretend-really-hard-to-be-posix-magic around in the Windows-port. In
fact, I have some patches to reduce posixness in some areas, while
getting rid of some code in mingw.c. Would such patches be welcome, or
is pretend-to-be-posix the governing portability approach? In some
cases, this comes at the expense of some performance (and quite a bit
of added cludge), which is a bit contradictory to the Git design IMO.
This is especially
true if you are making the "drop-privileges" part a helper function, no?
I don't follow this part. What exactly becomes more true by having a
drop-privileges function?
Anyway, I'm pretty pleased with how this turned out after inlining
serve() into main(), what do you think about this? I've also moved the
reordering of usage-string into a new patch that makes inetd_mode and
detach incompatible (they already are, it's just not checked for or
documented).
@@ -401,6 +401,7 @@ EXTRA_PROGRAMS =# ... and all the rest that could be moved out of bindir to gitexecdirPROGRAMS+=$(EXTRA_PROGRAMS)+PROGRAM_OBJS+=daemon.oPROGRAM_OBJS+=fast-import.oPROGRAM_OBJS+=imap-send.oPROGRAM_OBJS+=shell.o
@@ -1126,14 +1125,15 @@ int main(int argc, char **argv) /* avoid splitting a message in the middle */ setvbuf(stderr, NULL, _IOFBF, 4096);- if (inetd_mode && (detach || group_name || user_name))- die("--detach, --user and --group are incompatible with --inetd");- if (inetd_mode && (listen_port || (listen_addr.nr > 0))) die("--listen= and --port= are incompatible with --inetd"); else if (listen_port == 0) listen_port = DEFAULT_GIT_PORT;+#ifndef NO_POSIX_GOODIES+ if (inetd_mode && (detach || group_name || user_name))+ die("--detach, --user and --group are incompatible with --inetd");+ if (group_name && !user_name) die("--group supplied without --user");
@@ -1145,13 +1145,14 @@ int main(int argc, char **argv) if (!group_name) gid = pass->pw_gid; else {- group = getgrnam(group_name);+ struct group *group = getgrnam(group_name); if (!group) die("group not found - %s", group_name); gid = group->gr_gid; } }+#endif if (strict_paths && (!ok_paths || !*ok_paths)) die("option --strict-paths requires a whitelist");
@@ -1168,11 +1169,13 @@ int main(int argc, char **argv) if (inetd_mode || serve_mode) return execute();+#ifndef NO_POSIX_GOODIES if (detach) { daemonize(); loginfo("Ready to rumble"); } else+#endif sanitize_stdfds(); if (pid_file)
@@ -1185,5 +1188,15 @@ int main(int argc, char **argv) cld_argv[argc] = "--serve"; cld_argv[argc+1] = NULL;- return serve(&listen_addr, listen_port, pass, gid);+ socksetup(&listen_addr, listen_port, &socklist);+ if (socklist.nr == 0)+ die("unable to allocate any listen sockets on port %u",+ listen_port);++#ifndef NO_POSIX_GOODIES+ if (pass && gid)+ drop_privileges(pass, gid);+#endif++ return service_loop(&socklist); }
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:48
Hi,
A response to the general questions.
Erik Faye-Lund wrote:
On Fri, Oct 15, 2010 at 11:16 PM, Junio C Hamano [off-list ref] wrote:
quoted
Why does the signature even have to be different between the two to begin
with? I _think_ you have gid_t over there
We don't, so this is the primary reason.
Just to throw an idea out: you can also do something like
#ifndef NO_POSIX_GOODIES
struct credentials {
};
#else
struct credentials {
struct passwd *pass;
gid_t gid;
}
#endif
and pass a pointer to credentials around.
But also avoiding
compilation-warnings is a secondary motivation.
(void) gid;
works for this.
We do, so this becomes a bit of a hypothetical question. But would you
seriously consider pretending to have a posix-feature less ugly than
inlining a function that is only used once?
In general, yes.
Long functions can make code much, much more difficult to read. A
fake posix feature just requires some suspension of disbelief.
In this case (#ifdef-heavy main() vs opaque struct passwd), both
strike me as ugly.
(I'm going a little off-topic here, I hope that's OK)
I'm not too happy with some of the
pretend-really-hard-to-be-posix-magic around in the Windows-port. In
fact, I have some patches to reduce posixness in some areas, while
getting rid of some code in mingw.c. Would such patches be welcome, or
is pretend-to-be-posix the governing portability approach? In some
cases, this comes at the expense of some performance (and quite a bit
of added cludge), which is a bit contradictory to the Git design IMO.
Sometimes the best abstraction is the posix one and sometimes not. I
don't think this would contradict with your planned patches, unless
they introduce #ifdefs all over the place.
quoted
This is especially
true if you are making the "drop-privileges" part a helper function, no?
I don't follow this part. What exactly becomes more true by having a
drop-privileges function?
(See linux-2.6.git:Documentation/SubmittingPatches, section "#ifdefs
are ugly".)
The ideal: never an #ifdef within a function. (Well, the ideal is
no #ifdef-s in .c files, but that's harder to take seriously.)
#ifndef HAVE_POSIX_GOODIES
static int drop_privileges(...)
{
return error("--user and --group not supported on this platform");
}
#endif
static int drop_privileges(...)
{
...
do
something
...
}
#endif
would make serve() look like
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
if (want to drop privileges) {
if (drop_privileges(...))
return -1;
}
return service_loop(socknum, socklist);
}
which should be quite readable even to a person only interested in the
!HAVE_POSIX_GOODIES case imho. With some code rearrangement it could
be made nicer. Now compare:
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
#ifdef HAVE_POSIX_GOODIES
...
do
things
...
#endif
return service_loop(socknum, socklist);
}
Just my two cents. Sorry I do not have something more substantive to
say.
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:49:50
On Mon, Oct 18, 2010 at 6:31 PM, Jonathan Nieder [off-list ref] wrote:
A response to the general questions.
Thanks!
Erik Faye-Lund wrote:
quoted
On Fri, Oct 15, 2010 at 11:16 PM, Junio C Hamano [off-list ref] wrote:
quoted
quoted
Why does the signature even have to be different between the two to begin
with? I _think_ you have gid_t over there
We don't, so this is the primary reason.
Just to throw an idea out: you can also do something like
#ifndef NO_POSIX_GOODIES
struct credentials {
};
#else
struct credentials {
struct passwd *pass;
gid_t gid;
}
#endif
and pass a pointer to credentials around.
Yes, but that structure still needs to be filled somehow. I'm not sure
how this solves anything, really. Isn't it essentially another way of
wrapping an ifdef around the parameters inside main() (at least when
I've inlined serve() into main())?
quoted
quoted
This is especially
true if you are making the "drop-privileges" part a helper function, no?
I don't follow this part. What exactly becomes more true by having a
drop-privileges function?
(See linux-2.6.git:Documentation/SubmittingPatches, section "#ifdefs
are ugly".)
The ideal: never an #ifdef within a function. (Well, the ideal is
no #ifdef-s in .c files, but that's harder to take seriously.)
#ifndef HAVE_POSIX_GOODIES
static int drop_privileges(...)
{
return error("--user and --group not supported on this platform");
}
#endif
static int drop_privileges(...)
{
...
do
something
...
}
#endif
would make serve() look like
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
if (want to drop privileges) {
if (drop_privileges(...))
return -1;
}
return service_loop(socknum, socklist);
}
which should be quite readable even to a person only interested in the
!HAVE_POSIX_GOODIES case imho. With some code rearrangement it could
be made nicer. Now compare:
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
#ifdef HAVE_POSIX_GOODIES
...
do
things
...
#endif
return service_loop(socknum, socklist);
}
Just my two cents. Sorry I do not have something more substantive to
say.
You're leaving out the troublesome part, namely the glue between "if
(user_name)" in main(), and the "want to drop privileges"-stuff in
serve().
I could do a "struct credentials *cred = NULL;" in main(), and assign
that inside "if (user_name)". But that'd leave a warning about
unreachable code in drop_privileges(), no?
I'm also getting the feeling that I'm being hinted at to implement
proper credential-dropping (ie filling out the windows-versions of the
code with something that makes sense for windows), but this isn't how
these things work on Windows. Daemons run as services on Windows, and
what user to run a service under is a system-administrator setting. In
fact, you can't even impersonate another user without having it's
password.
Turning git-daemon into a service is something that can be done later.
I've looked into it, and what seems to make the most sense is to have
a separate mode on git-daemon (or even another program), that starts
git-daemon as a subprocess. This is because of the way Windows
communicates with the service, requiring a message-loop that can be
terminated.
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:49:50
On Thu, Oct 21, 2010 at 11:16 PM, Erik Faye-Lund [off-list ref] wrote:
On Mon, Oct 18, 2010 at 6:31 PM, Jonathan Nieder [off-list ref] wrote:
quoted
Just to throw an idea out: you can also do something like
#ifndef NO_POSIX_GOODIES
struct credentials {
};
#else
struct credentials {
struct passwd *pass;
gid_t gid;
}
#endif
and pass a pointer to credentials around.
Yes, but that structure still needs to be filled somehow. I'm not sure
how this solves anything, really. Isn't it essentially another way of
wrapping an ifdef around the parameters inside main() (at least when
I've inlined serve() into main())?
quoted
#ifndef HAVE_POSIX_GOODIES
static int drop_privileges(...)
{
return error("--user and --group not supported on this platform");
}
#endif
static int drop_privileges(...)
{
...
do
something
...
}
#endif
would make serve() look like
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
if (want to drop privileges) {
if (drop_privileges(...))
return -1;
}
return service_loop(socknum, socklist);
}
which should be quite readable even to a person only interested in the
!HAVE_POSIX_GOODIES case imho. With some code rearrangement it could
be made nicer. Now compare:
static int serve(...)
{
int socknum, *socklist;
... setup socket ...
#ifdef HAVE_POSIX_GOODIES
...
do
things
...
#endif
return service_loop(socknum, socklist);
}
Just my two cents. Sorry I do not have something more substantive to
say.
You're leaving out the troublesome part, namely the glue between "if
(user_name)" in main(), and the "want to drop privileges"-stuff in
serve().
I could do a "struct credentials *cred = NULL;" in main(), and assign
that inside "if (user_name)". But that'd leave a warning about
unreachable code in drop_privileges(), no?
OK, I did another stab at this, and this is the best I could come up
with right now, what do you think?
@@ -401,6 +401,7 @@ EXTRA_PROGRAMS =# ... and all the rest that could be moved out of bindir to gitexecdirPROGRAMS+=$(EXTRA_PROGRAMS)+PROGRAM_OBJS+=daemon.oPROGRAM_OBJS+=fast-import.oPROGRAM_OBJS+=imap-send.oPROGRAM_OBJS+=shell.o
@@ -938,6 +940,33 @@ static void sanitize_stdfds(void)close(fd);}+#ifdef NO_POSIX_GOODIES++structcredentials;+staticvoiddrop_privileges(structcredentials*cred)+{+/* nothing */+}++staticvoiddaemonize(void)+{+die("--detach not supported on this platform");+}++#else++structcredentials{+structpasswd*pass;+gid_tgid;+};++staticvoiddrop_privileges(structcredentials*cred)+{+if(cred&&initgroups(cred->pass->pw_name,cred->gid)||+setgid(cred->gid)||setuid(cred->pass->pw_uid))+die("cannot drop privileges");+}+staticvoiddaemonize(void){switch(fork()){
@@ -1126,32 +1158,37 @@ int main(int argc, char **argv) /* avoid splitting a message in the middle */ setvbuf(stderr, NULL, _IOFBF, 4096);- if (inetd_mode && (detach || group_name || user_name))- die("--detach, --user and --group are incompatible with --inetd");- if (inetd_mode && (listen_port || (listen_addr.nr > 0))) die("--listen= and --port= are incompatible with --inetd"); else if (listen_port == 0) listen_port = DEFAULT_GIT_PORT;+#ifndef NO_POSIX_GOODIES+ if (inetd_mode && (detach || group_name || user_name))+ die("--detach, --user and --group are incompatible with --inetd");+ if (group_name && !user_name) die("--group supplied without --user"); if (user_name) {- pass = getpwnam(user_name);- if (!pass)+ struct credentials c;+ cred = &c;++ c->pass = getpwnam(user_name);+ if (!c->pass) die("user not found - %s", user_name); if (!group_name)- gid = pass->pw_gid;+ c->gid = pass->pw_gid; else {- group = getgrnam(group_name);+ struct group *group = getgrnam(group_name); if (!group) die("group not found - %s", group_name);- gid = group->gr_gid;+ c->gid = group->gr_gid; } }+#endif if (strict_paths && (!ok_paths || !*ok_paths)) die("option --strict-paths requires a whitelist");
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:49:50
On Fri, Oct 22, 2010 at 12:00 AM, Erik Faye-Lund [off-list ref] wrote:
if (user_name) {
- pass = getpwnam(user_name);
- if (!pass)
+ struct credentials c;
+ cred = &c;
+
+ c->pass = getpwnam(user_name);
+ if (!c->pass)
die("user not found - %s", user_name);
if (!group_name)
- gid = pass->pw_gid;
+ c->gid = pass->pw_gid;
else {
- group = getgrnam(group_name);
+ struct group *group = getgrnam(group_name);
if (!group)
die("group not found - %s", group_name);
- gid = group->gr_gid;
+ c->gid = group->gr_gid;
}
}
Sorry for the noise, but this is clearly incorrect and won't compile.
I guess replacing "c->" with "c." should do the trick :)
If I got this way, I'll obviously make sure it compiles! ;)