On Tue, Sep 09, 2008 at 10:13:41PM -0500, Shawn Walker wrote: >> And why is os.getlogin() better than the getpwuid() call? > > Because os.getlogin() returns the actual, current username based on > environment variables, etc. In short, it makes it possible for history to > record the user that did "pfexec pkg install foo". getuid(), etc. work off > the current/effective user id which is always 0 with pfexec on a default > osol 2008.05 install.
Ah, it sets uid, rather than euid? That's unfortunate. We should fix that, but yeah, I guess this is the best for now. >>>> - line 150: this seems like a risky assumption. If you're not going >>>> to implement a stack (one possibility), perhaps at least dump out all >>>> that you've gathered for the previous operation, with a end state of >>>> "incomplete". >>> It was a risky, but intentional assumption. Currently, none of our >>> clients perform multiple operations synchronously. >> >> Not on purpose. But as soon as someone puts two of these operations >> together in a way you didn't anticipate, we lose data. > > A stack doesn't solve all the problem either though. > > A stack only solves the situation where: > > A starts, B starts > B ends, A ends > > ...if B ends after A ends, a stack doesn't work. True. Though given that end_operation() doesn't take an operation name (or a handle returned by start_operation), then there's no way to detect the non-stack case. At best you can keep a depth count, which is one reason I suggested a stack. Another is that while a stack of operations makes some amount of sense, a non-stack doesn't, as far as I can tell. It simply indicates programming error. Again, I dunno if you can ever tell, so for the paranoid, erroring out when you start a second operation before closing out a first is really the only thing to do. I'd like not to be that paranoid, but it's up to you. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
