Subject Re: [firebird-support] permission denied
Author Jason Dodson
The idea being that you generally don't have a filesystem "defragger". A
unix filesystem is different then that of, say Windows.

User tools, system libraries and such will never really change. If they
do, it SHOULDNT be that often. So they go into a part of the
filesystem/disk that is optimized (or should be) for this kind of
operation. And with that, lots or creating/deleting/writing files can
really affect your file system performance.

/var is part of the filesystem (and generally coordinated the same on
the disk) that is meant for heavy IO. On bigger servers, this is where
you would have your most speedy, high-end disk. When it is part of the
same physical disk as the rest of the system, it at least is the only
place that should ever have fragmentation... and with that, the only
place that fragmentation is maintained... So it is quick and efficient.

/tmp is usually a symlink to /var/tmp. Also, just being under /var
doesn't imply that it is free for the world to grab at. Mailboxes under
/var/spool/mail for instance only allow the owner of the mailbox and
mail to access them. System logs under /var/log are only readable by root.

Anyway, like Helen said, it probably really doesn't matter :|


Helen Borrie wrote:
> At 05:17 PM 17/04/2005 +1000, you wrote:
>>>3) it is not a Good Thing (TM) to grant other users privileges in root's
>>>home directory. I suggest you create a filesystem tree called /data (or
>>>similar) and make that the firebird user's "patch".
>>Will do. Or at least I'll ask Jason why it would be better to use /var.
> It doesn't matter what it's called. But /var is a special-purpose
> filesystem on *x versions that use it, generally for storing program
> variable data. I suppose you could think of a database files as program
> variable data. :-) I'm more for considering permissions. A database file
> is "private space" - it should be accessible only to those who need to
> access it as a file.
> btw, it makes a lot of sense to create a firebird group, of which the
> firebird user and (where required) the database users. Then you can give
> the firebird user owner privs in the spaces where it needs them, and give
> group privs to the spaces where owner privs are not required.