Subject | Re: [ib-support] Firebird install.sh and Linux/Unix |
---|---|
Author | Paul Schmidt |
Post date | 2002-07-02T12:31:20Z |
On 28 Jun 2002 at 13:51, William L. Thomson Jr. wrote:
could run as root or as it's own user created it's own user and group you could end
up with hundreds or thousands of users just for maintenance. For example if you
have Firebird, PostgreSQL, mySQL, Sybase and Oracle installed you could end up
with 5 separate users just for databases. Some people might want to run them all
under one user id. Second it could create it's own security problems, some people
might think that Firebird is just too obvious for security reasons.
replacing the password field in the /etc/passwd file with a *. You need to make sure
that shadow passwords are turned off before you do this, (you can convert from
shadow to non-shadow fix the password and the convert back). The only way to
access it then is by logging in as root, and using the su command.
Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com
> Just a thought for others to comment on. Shouldn't each service underYes, that's why there is a change user script in the Firebird directory....
> a Posix compliant OS run under restricted users and groups not
> root/su.
> So if possible can it be added to the Firebird installer that a userI don't agree with this idea, for a couple of reasons, one is that if every app that
> and group be created that Firebird will run under.
could run as root or as it's own user created it's own user and group you could end
up with hundreds or thousands of users just for maintenance. For example if you
have Firebird, PostgreSQL, mySQL, Sybase and Oracle installed you could end up
with 5 separate users just for databases. Some people might want to run them all
under one user id. Second it could create it's own security problems, some people
might think that Firebird is just too obvious for security reasons.
> I have had my installation of InterBase and InterClient running thisThis can be made very difficult if you disable the password to that account, by
> way for a while without any problems. Which should also help in case
> someone was able to get control of those accounts or services the
> damage would be limited to the user and the group the services belong
> to.
replacing the password field in the /etc/passwd file with a *. You need to make sure
that shadow passwords are turned off before you do this, (you can convert from
shadow to non-shadow fix the password and the convert back). The only way to
access it then is by logging in as root, and using the su command.
> So if an exploit or vulnerability arises it would not be a rootThey don't need to be members of the root group.
> exploit. So in my situation I have a user and group that IB runs
> under. I have a separate user and group that InterClient runs under.
> InterClient's group also includes the group that IB belongs to. Both
> IB and InterClient's group are also members of the root group,
> although I am not to sure that was necessary.
> Or am I doing all of this for nothing?Security can be a real PITA, but it beats getting hacked.
Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com