On Mon, 2005-07-04 at 16:21 +1000, Nick Blievers wrote:
> 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.
> 


i'll give it a test later, and let you know. 
thanks

> 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,
> >
> >
> >  
> >
-- 
=========================================================
Nir Tzachar.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to