On Jan 4, 4:23 pm, Cameron Simpson <c...@zip.com.au> wrote:
> On 04Jan2010 09:16, cassiope <f...@u.washington.edu> wrote:
> | To Cameron: the file doesn't (yet) exist; and it has the correct full
> | path.
>
> Can you show us the strace output of the failing open() call?
Ah...presumably you mean:
[pid 1976] open("/var/tmp/share/lvrq-Robert.Smith", O_WRONLY|
O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
> | To "Nobody" : hey, this seems interesting. First test, invoking
> | seteuid()
> | and setegid() didn't help - but strange thing was these calls didn't
> | show
> | up in the strace, so perhaps I wasn't testing what I thought I was.
>
> If you're using the "-e trace=file" option it won't. That constrains the
> output to file operations to make the log easier to read. Discard the -e
> option to get everything.
>
> Cheers,
> --
> Cameron Simpson <c...@zip.com.au> DoD#743http://www.cskk.ezoshosting.com/cs/
Wasn't using the -e option. It turns out that the compiler was
changing the
code to use the linux functions setresgid() and setresuid(). That's
why I
didn't see it previously.
If I only use the seteuid/setegid, it "works" - it is able to write
the file.
Unfortunately this may be partly due to its incompletely dropping
priviledges -
the file has root ownership, not "lesser user" ownership.
Using setuid/setgid or setresuid/setresgid where just real OR both
real and
effective identities are set to "lesser user" - it still doesn't work
- no file
is written. Again, "lesser user" has no problem writing a file into
this
directory.
I remain mystified :(
Thanks for your valiant efforts!
--
http://mail.python.org/mailman/listinfo/python-list
