Re: [E-devel] entrance problem with nfs
Carsten Haitzler (The Rasterman) wrote: >On Mon, 04 Jul 2005 16:21:05 +1000 Nick Blievers <[EMAIL PROTECTED]> babbled: > > > >>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. >> >> > >patch in - seems innocuous enough :) > > Can someone please check that the debug logging calls will work when called as a non-root user? That is my main concern with it. Nick PS You mayaswell either remove the commented out chown() call, or uncomment it. Either should be safe. BTW I'm actually running e16 as my full time window manager on my IRIX box now, and the new default theme rocks! --- 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
Re: [E-devel] entrance problem with nfs
On Mon, 04 Jul 2005 16:21:05 +1000 Nick Blievers <[EMAIL PROTECTED]> babbled:
> 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.
patch in - seems innocuous enough :)
> 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.c17 May 2004 05:31:49 -1.15
> +++ daemon/auth.c4 Jul 2005 06:24:23 -
> @@ -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,
> >
> >
> >
> >
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
---
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
Re: [E-devel] entrance problem with nfs
the patch works. thanks a lot. would it be included in the cvs --- 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
Re: [E-devel] entrance problem with nfs
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. ok, gave it a try, but for some reason i cant get entrance to run at all now... i dont think its related to the patch. i'll try a fresh install from cvs tonight, and keep you posted. thanks. -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part
Re: [E-devel] entrance problem with nfs
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.c17 May 2004 05:31:49 -1.15
> +++ daemon/auth.c4 Jul 2005 06:24:23 -
> @@ -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.
signature.asc
Description: This is a digitally signed message part
Re: [E-devel] entrance problem with nfs
On Mon, 04 Jul 2005 08:55:13 +0300 Nir Tzachar <[EMAIL PROTECTED]> babbled: > > 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 harder? jhahahahahha "i need to access file owned by uid X - add user of uid X if doesn't exist, or just su - username" and then do the work. its no barrier at all. it simply makes system administration and stuff more painful :( > 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. any cracker who has gotten that far can get the few extra steps - its no real solution. it just makes life painful. its worse than "security by obscurity". :) > > 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). ahahahhahaha! well ok - you have a weird idea of security :) > > 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. well patches accepted. :) > > 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. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] entrance problem with nfs
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.c17 May 2004 05:31:49 -1.15
+++ daemon/auth.c4 Jul 2005 06:24:23 -
@@ -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
Re: [E-devel] entrance problem with nfs
> 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. signature.asc Description: This is a digitally signed message part
Re: [E-devel] entrance problem with nfs
On Sun, 3 Jul 2005 19:44:54 +0300 (IDT) Nir Tzachar <[EMAIL PROTECTED]> babbled: > but again, if you had hundreds of users, whose work you had to keep backed > up (and allow them to restore files online), what other solution would you > use?? we use several network appliance machines, exporting users' home > dirs via nfs. no better solution there. 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). that was his point - its an option that may mistakenly make people think their file exports are "more secure" :) > to sum things up, we currently cannot use entranced. we'd really like to. > we would patch it ourselves if we had more time to read the code > as always, the expected followup would say "dont expect anyone else to > scratch your itch". we dont expect it, and can make do till (if..) > someone else will fix it. if you dont consider it broken, then toughs for > us, but please let us know. you can use it - in a few minutes with no code changes. remove root squash. it's a pointless option (as above) :) 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 :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] entrance problem with nfs
Nir Tzachar wrote: You didn't insult him. You just acted as though you knew more than he about his own program. So he decided that you could fend for yourself. Seems perfectly reasonable to me. well, i still think i know more than him (and you) about MY problem. i am the most qualified person to talk about my problems, and if someone thinks im a dickhead for thinking it, toughs for him. Well since you insist that you know everything, why are you bothering us? Go fix it for yourself! Like I said before, I'd give you an answer on this but you just are not worth it. Ibukun --- 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
Re: [E-devel] entrance problem with nfs
> 1. You have a question. A somewhat silly one, but a question > nonetheless. YOU consider it silly. > > 2. You post it to the developers list hoping for an answer. first posted to the user list, got no answer. then posted to devel list, got no answer. reposted, got an answer after several days. > 3. The author of the program your question concerns responds with an > answer pointing out your oversight. points where??? > 4. You rudely and haughtily tell him he's wrong as if he wouldn't > know what he's talking about. i now am sure he does. but i as of the time i wrote my answer, i had no idea he is the one who wrote entrance. he failed to mention such a small fact in his answer. > You didn't insult him. You just acted as though you knew more than he > about his own program. So he decided that you could fend for > yourself. Seems perfectly reasonable to me. well, i still think i know more than him (and you) about MY problem. i am the most qualified person to talk about my problems, and if someone thinks im a dickhead for thinking it, toughs for him. > Using "NFS" and "security" in the same thought process without the > phrase "has no" in between reveals a rather disturbing lack of clue on > your part. but again, if you had hundreds of users, whose work you had to keep backed up (and allow them to restore files online), what other solution would you use?? we use several network appliance machines, exporting users' home dirs via nfs. no better solution there. to sum things up, we currently cannot use entranced. we'd really like to. we would patch it ourselves if we had more time to read the code as always, the expected followup would say "dont expect anyone else to scratch your itch". we dont expect it, and can make do till (if..) someone else will fix it. if you dont consider it broken, then toughs for us, but please let us know. cheers, -- nir. --- 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
Re: [E-devel] entrance problem with nfs
This is getting out of hand. Please, everybody, go back to your respective corners for some time out. We will proceed around the same time tomorrow, hopefully with cooler heads. Thank you. Azundris! --- 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
Re: [E-devel] entrance problem with nfs
On Sunday, 03 July 2005, at 10:53:11 (+0300), Nir Tzachar wrote: > why the attitude? Maybe because you're acting like a dickhead? Let's review the timeline, shall we? 1. You have a question. A somewhat silly one, but a question nonetheless. 2. You post it to the developers list hoping for an answer. 3. The author of the program your question concerns responds with an answer pointing out your oversight. 4. You rudely and haughtily tell him he's wrong as if he wouldn't know what he's talking about. While #2 was a minor mistake (you should've posted to the users list), it's #4 that makes you look like a dumbass. > have i insulted you in any way? i dont think so. You didn't insult him. You just acted as though you knew more than he about his own program. So he decided that you could fend for yourself. Seems perfectly reasonable to me. > we have several hundreds of users, whose accounts sit on a central > nfs server. as is accustomed in these circumstances, we set the nfs > to root squash, from security reasons. Using "NFS" and "security" in the same thought process without the phrase "has no" in between reveals a rather disturbing lack of clue on your part. > bye. See ya. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "Without the hope that things will get better, that our inheritors will know a world that is fuller and richer than our own, life is pointless, and evolution is vastly overrated." -- Mira Furlan (Ambassador Delenn), Babylon Five --- 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
Re: [E-devel] entrance problem with nfs
> Of course. Since I wrote the stupid program myself, I have no idea what > the heck I'm talking about. I'd give you an answer but you don't deserve > one, so I'll let you figure it out on your own, oh wise one. why the attitude? have i insulted you in any way? i dont think so. even so, i apologize. i didnt know you wrote the progi, but this may help, as you probably the one most familiar with the code. entrance is a beautiful display manager, and we'd really like to deploy it in our site. we have several hundreds of users, whose accounts sit on a central nfs server. as is accustomed in these circumstances, we set the nfs to root squash, from security reasons. this has worked till now, and entranced is the _only_ display manager which cannot handle it. a pitty. All i asked is a simple question. a "no, we will not support root squash. maybe when hell froze over" would be acceptable. it will mean we will not use entrance, though, but there are other options. personally, i would not like to hear such an answer, and would prefer smthing like "no, we dont support it yet. if you want, implement it yourself". i'd do that, but first i need the reasons why it wasn't supported in the first place. bye. -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part
Re: [E-devel] entrance problem with nfs
Nir Tzachar wrote: On Thu, 2005-06-30 at 09:38 -0500, Ibukun Olumuyiwa wrote: Nir Tzachar wrote: hello. entrance have a problem with users whose home dirs reside on nfs. if the nfs export is set to root-squash, entrance does not succeed in creating the authentication file (.Xauthority). i guess the problem is it does not set it's uid at the appropriate time, but im shooting blind here The problem is not manifested with local users, but only in the scenario mentioned above. any ideas??? has someone else ever tried this?? Well, I hate to say "duh", but you specifically configured your NFS mount to prevent root from writing, and you are complaining that entrance cannot write? hi. thanks for answering ;) anyway, you are wrong. as an example, look at xdm. works like a charm as i said, it looks like entranced does not seteuid before writing to the user's .xauthority. Of course. Since I wrote the stupid program myself, I have no idea what the heck I'm talking about. I'd give you an answer but you don't deserve one, so I'll let you figure it out on your own, oh wise one. --- 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
Re: [E-devel] entrance problem with nfs
On Thu, 2005-06-30 at 09:38 -0500, Ibukun Olumuyiwa wrote: > Nir Tzachar wrote: > > hello. > > > > entrance have a problem with users whose home dirs reside on nfs. > > if the nfs export is set to root-squash, entrance does not succeed in > > creating the > > authentication file (.Xauthority). > > i guess the problem is it does not set it's uid at the appropriate time, > > but im > > shooting blind here > > The problem is not manifested with local users, but only in the scenario > > mentioned above. > > > > any ideas??? has someone else ever tried this?? > > > > Well, I hate to say "duh", but you specifically configured your NFS > mount to prevent root from writing, and you are complaining that > entrance cannot write? hi. thanks for answering ;) anyway, you are wrong. as an example, look at xdm. works like a charm as i said, it looks like entranced does not seteuid before writing to the user's .xauthority. -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part
Re: [E-devel] entrance problem with nfs
Nir Tzachar wrote: hello. entrance have a problem with users whose home dirs reside on nfs. if the nfs export is set to root-squash, entrance does not succeed in creating the authentication file (.Xauthority). i guess the problem is it does not set it's uid at the appropriate time, but im shooting blind here The problem is not manifested with local users, but only in the scenario mentioned above. any ideas??? has someone else ever tried this?? -- Ibukun Olumuyiwa http://xcomputerman.com "I will stand upon my watch, and set me upon the tower, and will watch to see what he will say unto me, and what I shall answer when I am reproved." --- 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
Re: [E-devel] entrance problem with nfs
Nir Tzachar wrote: hello. entrance have a problem with users whose home dirs reside on nfs. if the nfs export is set to root-squash, entrance does not succeed in creating the authentication file (.Xauthority). i guess the problem is it does not set it's uid at the appropriate time, but im shooting blind here The problem is not manifested with local users, but only in the scenario mentioned above. any ideas??? has someone else ever tried this?? Well, I hate to say "duh", but you specifically configured your NFS mount to prevent root from writing, and you are complaining that entrance cannot write? -- Ibukun Olumuyiwa http://xcomputerman.com "I will stand upon my watch, and set me upon the tower, and will watch to see what he will say unto me, and what I shall answer when I am reproved." --- 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
[E-devel] entrance problem with nfs
hello. entrance have a problem with users whose home dirs reside on nfs. if the nfs export is set to root-squash, entrance does not succeed in creating the authentication file (.Xauthority). i guess the problem is it does not set it's uid at the appropriate time, but im shooting blind here The problem is not manifested with local users, but only in the scenario mentioned above. any ideas??? has someone else ever tried this?? -- = Nir Tzachar. signature.asc Description: This is a digitally signed message part
