Ok, Firebird is NOT a desktop application. People shouldn't be "screwing" with it, like they would their locally
installed version of Microsoft Office or Yahoo Instant Massager. At WORST, you should have ONE server administrator, and
possibly ONE firebird admin. In a lot of cases, these just may be the same person. In either case, said admins will have
proper rights to su root... or at least have explicit rights otherwise to do their job.

If you argue this is for "testing purposes", grab an piece of VM software like Bochs, install Loonix, and test on your
own virtual machine, where YOU ARE THE ADMIN.

Relaxing security, EVEN FOR THE SAKE OF CONVENIENCE, is an absurd notion, especially on something like database server
software.

Jason

Rick Debay wrote:

>> Why? Usre 'firebird' is a pseudo-user, in which context fbserver runs.
>> Suppose someone (bad guy) found a way to run his code in context of
>> firebird server (due to some BOF, bad firebird.conf - or something
>> else). If some programs, scripts belong to user 'firebird', he can
>> modify it. With current root ownership - he can't. Why do you want to
>> make production system less protected?
>
> If the server process is compromised, I think the ability to modify
> server scripts is not what anyone has to worry about. It's a fallacy
> that making everything root access only is secure. And I'm not saying
> the script has to be writable by the firebird group, but it needs to be
> executable by them.
>
>> Please agree, that access to the server and ability to start-stop it
> are
>> a bit different things. For today, two users can stop server - root
> and
>> firebird. And for me, this is absolutely correct.
>
> The problem is that by making root the only account that can maintain
> the system, everyone is required to have root access and that security
> hole is by far the worst.
> This problem is greatly reduced by blocking remote root access,
> requiring wheel membership to su to root, and seperating root
> permissions out to those who need it in the sudoers file. However,
> sudoer files can become very complex very quickly, and it's easy to
> accidentally lock someone out or grant unwanted permissions. I'd be
> prone to give Joe Database Operator and Jane Database Operator
> permissions (by group membership) to run all scripts and programs
> belonging to the firebird group. That way they can backup, sweep,
> bounce the server, etc. But root (or a System Operator alias in
> sudoers) would be required to upgrade the server code or change the
> server's runlevel.
>
> Perhaps part of the review would be to create a sudoer alias, and
> permissions for the various actions, and placed in a sample file. Then
> it could be appended to the sudoer file if the installer wanted to.
>
> Rick DeBay
>
> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Alex Peshkov
> Sent: Tuesday, March 28, 2006 3:57 AM
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] Firebird init script
>
> Rick Debay wrote:
>> You are correct, I just checked our rpm install of the beta and while
>> the comment is still there, the code is not. I will have to check the
>
>> tarball install, I could swear it contained the old script. Or
>> perhaps we installed the wrong tarball on the test system.
>>
>
> post-install script in rpm and tar is exactly the same - it's simply the
> same file. But as far as I remember you were initially talking about
> 1.5? In it there IS the sysdba password, and for security reasons file
> must be 0600.
>
>>> For production system suggested feature is a bad thing.
>> I don't understand. Anyone who can run kill as root can of course
> stop
>> the server. But the comment in the script suggested that only root
>> should be able to stop the server.
>
> I plan to review whole linux setup soon, including comments fixing.
>
>> I wanted to make sure that any
>> shutdown scripts, programs, etc belong to the firebird group, and not
>> root.
>>
>
> Why? Usre 'firebird' is a pseudo-user, in which context fbserver runs.
> Suppose someone (bad guy) found a way to run his code in context of
> firebird server (due to some BOF, bad firebird.conf - or something
> else). If some programs, scripts belong to user 'firebird', he can
> modify it. With current root ownership - he can't. Why do you want to
> make production system less protected?
>
>> On our test system they're all owned by
>> root (We log on as root to the test systems. In production that's not
>> done, of course).
>
> Normally all services on production system are controlled by root. Did
> you try, for example, to restart named beeing a member of named group?
>
> Group firebird was primarily designed for embedded access to the server.
>
> Please agree, that access to the server and ability to start-stop it are
>
> a bit different things. For today, two users can stop server - root and
> firebird. And for me, this is absolutely correct.
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

--
The information transmitted herewith is sensitive information intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.