> Given that the "-o" flag affects only protocol preferences,
> and the file
> permissions aren't a protocol preference - in fact, it's not a
> preference at all - the answer is "no".
Okay, simple enough.
> > It seems that
> > sometimes ethereal/tethereal saves the capture files with a
> '0600' file
> > permission
>
> "Sometimes"? That's the default behavior.
> We could use 0644 and let the umask take away undesired read
> permissions, but that might not be what all users want - it's
> easier to
> give people read permissions afterwards than to retroactively
> take away
> read permission after somebody's already read a file, and
> capture files
> sometimes contain sensitive data.
>
> We could also perhaps have the temporary capture files
> created with 0600
> and have "Save" change the permissions of the file, although
> again that
> might give public read permission when that's not desired.
>
> Having Ethereal control the access rights to files gets more
> complicated
> on systems with ACLs (systems in the Windows NT line,
> including W2K (NT
> 5.0), WXP (NT 5.1), and W2K3 Server (NT 5.2), and some UN*Xes).
Yeah, that is all understandable and I agree with it fully. I was under a
different assumption on its default saving patterns. Thanks for letting me
know how it is supposed to be acting.
This means I unfortunately have something odd going on with my system. Not
sure why, but sometimes the captures are being saved 'rw-r--r--' (644), and
sometimes they are 'rw-------' (600). I'll have to look into this and see
what else might be causing that to happen. 'ethereal -v' provides:
[root@atl-snf01 root]# ethereal -v
ethereal 0.10.3
Compiled with GTK+ 1.2.10, with GLib 1.2.10, with libpcap 0.7.2,
with libz 1.1.4, without libpcre, with Net-SNMP 5.0.9, without ADNS.
NOTE: this build does not support the "matches" operator for Ethereal filter
syntax.
Running with libpcap (version unknown) on Linux 2.4.21-20.ELsmp.
-gabriel
