Aren't we talking about a really trivial patch here?

I dont have the means to test this, but something like this should work right? (the debug logging may not, and I know nothing about XauLockAuth and what it requires), but what is been asked for is very trivial.


Nick

eg
Index: daemon/auth.c
===================================================================
RCS file: /cvsroot/enlightenment/e17/apps/entrance/src/daemon/auth.c,v
retrieving revision 1.15
diff -u -r1.15 auth.c
--- daemon/auth.c    17 May 2004 05:31:49 -0000    1.15
+++ daemon/auth.c    4 Jul 2005 06:24:23 -0000
@@ -424,6 +424,7 @@
         d->client.authfile = strdup(buf);
      }

+      seteuid(d->client.uid);
      /* Make sure the file can be written to */
      if((auth_file = fopen(d->client.authfile, "a+")))
         fclose(auth_file);
@@ -432,6 +433,7 @@
entranced_debug("entranced_auth_user_add: Unable to write auth file %s\n", d->client.authfile);
         free(d->client.authfile);
         d->client.authfile = NULL;
+     seteuid(0);
         return FALSE;
      }
      /* TODO: May need a permissions/paranoia check */
@@ -446,6 +448,7 @@
         free(d->client.authfile);
         d->client.authfile = NULL;

+     seteuid(0);
         umask (022);
      }
      else
@@ -453,6 +456,7 @@
   }

   /* Open file and write auth entries */
+   seteuid(d->client.uid);
   if(!(auth_file = fopen(d->client.authfile, "r+")))
   {
syslog(LOG_CRIT, "entranced_auth_user_add: Open auth file %s failed after lock", d->client.authfile);
@@ -460,6 +464,7 @@
      free(d->client.authfile);
      d->client.authfile = NULL;

+      seteuid(0);
      umask (022);

      return FALSE;
@@ -483,9 +488,10 @@
   fclose(auth_file);
   XauUnlockAuth(d->client.authfile);
- chown(d->client.authfile, d->client.uid, d->client.gid);
+  // chown(d->client.authfile, d->client.uid, d->client.gid);

entranced_debug("entranced_auth_user_add: Finished writing auth entries to %s\n", d->client.authfile);
+   seteuid(0);

   return ret;

i think he was referring to using root-squash. it's an entirely pointless option
and does not make the nfs exporting any more secure (disallowing root access to
files like it would be allowed locally is pointless as if u are root - u can
setuid/seteuid or su to the user id u need then do your dirty work - it just
become more painful - that's all).
we _know_ nfs is not secure. we have no other _secure_ option. we use
nfs, and make life harder on a would-be intruder: the main concern in
our organization is an inside attack. since no one can close all holes,
the motto is "make intrusion as hard as possible".  one such way, is
using root squash.

that was his point - its an option that may
mistakenly make people think their file exports are "more secure" :)
we dont think it is more secure. we think it will give an intruder a hard time
(writing 2 extra command lines _is_ a hard time....).

you can use it - in a few minutes with no code changes. remove root squash. it's
a pointless option (as above) :)
not an option.

entrance uses method A for writing the
.Xautharity file ie write as root then chown. xdm uses method B - seteuid, then
write. BOTH are valid methods but method A happens to not work over nfs with
root-squash. since imho root-squash is a pointless option anyhow... both methods
are equally valid :)
ok. end of discussion. i thank you all for your answers and comments.
if, for some unknow reason you decide to support method B, we'll be
happy to use entranced. until then, we'll stick with kdm.

cheers,





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to