Sounds like the security issue involves only those who wish to build SAP
themselves and not those installing the binary. So perhaps a strong
warning in the devtools package that the build computer should be either
isolated from the network or protected by a very strong firewall.
(In response to the original message: I didn't know PGSQL wasn't going
to make replication freely available. I've told my boss that I was
looking forward to PG7.1 so I could research dumping MSSQL/NT on our
servers. We need replication for our current setup and we need ACID
capabilities that MySQL doesn't provide. Say all you want about
businesses can pay for this stuff. These guys pay for what they can
see. R&D, especially for implementing Linux or BSD has been my spare
time with no budget.)
Michael Brown wrote:
> OK - I'm getting there. They use their own make tool and build
> environment, which has made it a bit more complicated than "normal" RPMS.
> (The Pascal source code that didn't translate into correct assembler
> didn't help either, but I've fixed that problem now).
> The major problem at the moment is that the path "/usr/spool/sql" is
> hardcoded into lots of the SAP source files and development tools. This
> is not a problem once the system is installed, but it does cause a problem
> while building; during the build process, it will expect to be able to
> write to /usr/spool/sql (and will sulk if it can't).
> I have come up with the following solution:
> The sapdb-devtools package, which provides the several Perl scripts
> required to build the sapdb package, creates an empty directory
> /usr/spool/sql with owner root and permissions rwxrwxrwx.
> The sapdb package has a buildRequires:sapdb-devtools, so when building the
> sapdb package, /usr/spool/sql is publicly writable and the build process
> is happy.
> In the %install section, the files in /usr/spool/sql will be parsed for
> sensible values and then copied to $RPM_BUILD_ROOT/usr/spool/sql, which
> will have owner sapdb and permissions rwxr-xr-x.
> The sapdb package has a Conflicts:sapdb-devtools, which forces the
> publicly writable /usr/spool/sql from sabdb-devtools to be removed before
> the sapdb package is installed.
> There is a mild security problem in that /usr/spool/sql remains publicly
> writable while sapdb is being built.
> Can anyone think of a more elegant solution to this problem?
> Michael
--
Digital Wokan, Tribal Mage of the Electronics Age
Guerilla Linux Warrior
