On the odd chance people haven't seen this:
http://www.eweek.com/article2/0,1759,1728956,00.asp
German security researcher Stefan Esser has discovered
multiple vulnerabilities in smbfs, the mountable SMB (Server
Message Block) file system for Linux.
In an advisory made public
| I quite agree with your remarks, but I fear that you seem to forget a very
| important point : Samba/VMS is a port from a quite complicated software that
| comes from Unix, and is quite often updated. If you multiply the #ifdef
| for VMS specifics, you begin to have a lot of work each time a
I've been looking more at the source code and the way it's
compiled.
/STANDARD=VAXC is really not a good choice. It covers up too
many real and potential problems in the code.
I decided to try compiling with a better set of options which
I have included below. (the /ARCH = HOST
The disk on which I am testing (DISK$STORAGE) is ODS-5.
Bart.
PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING:
http://www.catb.org/~esr/faqs/smart-questions.html
I've been trying out the 2.2.7A kit on OpenVMS 7.3-1, and I've
noticed a problem I don't think I've seen mentioned here.
In the log.* file, I noticed there was a $GETDVI error after
every file accessed. So I looked around the source for where it
came from, and I see that the system call
In case it wasn't clear, I'm still seeing erros after changing
the call to what I posted in my first message: sys$getdviw and
the correct addressing mode.
The error message passed back says it's trying to do a GETDVI
with a device name that in fact contains a file specification
string.
I assume others have also seen the junk from [EMAIL PROTECTED] and
similar addresses advertising something from
http://www.szbookshop.com (though I'm not sure what, since it's in
8 bit characters).
I've reported this through SpamCop, but I'm not sure it will
do any good. The mail
