Database systems that store each relation in a separate operating system file…

Concept: A DBMS can enforce data-access permissions either through its own SQL-level privilege system (GRANT/REVOKE, WITH GRANT OPTION, and control down to individual operations or columns), or by delegating to the host operating system's file-protection mechanism — the read/write/execute bits on the file holding a relation. The two mechanisms differ fundamentally in granularity: OS file permissions are coarse — they distinguish only broad access modes, are scoped to a whole file, and carry no notion of a SQL “grant option” for propagating specific privileges to other users.

Application: Here, each relation is deliberately stored in its own OS file so that OS permissions can be applied per relation — storing more than one relation in a shared file would prevent that. Because OS file modes are only read/write/execute, the OS cannot separately flag INSERT, UPDATE, and DELETE — all of them reduce to the same underlying “write” action on the file, so distinguishing these SQL-level operations is genuinely difficult under OS authorization. Delegating the check to the operating system's built-in file-access routines is also commonly cited, in the standard textbook comparison, as adding less overhead than a separate DBMS-level evaluation of a stored privilege table — though the exact overhead in any real system depends on implementation details. However, OS file permissions have no equivalent of SQL's WITH GRANT OPTION or fine-grained, per-privilege delegation, so relying on the OS scheme actually gives the administrator LESS control over grants, not more.

Cross-check: Weighing each statement against what OS-level file authorization can and cannot do:

• “The administrator enjoys more control on the grant option” — OS file-mode bits carry no grant-option or privilege-propagation semantics at all, so the administrator ends up with LESS control over grants under this scheme, not more.

• “It is difficult to differentiate among the update, delete and insert authorizations” — consistent with OS permissions being limited to read/write/execute, which cannot distinguish these three SQL operations.

• “Cannot store more than one relation in a file” — consistent with the setup described: per-relation OS protection requires one relation per file.

• “Operations on the database are speeded up as the authorization procedure is carried out at the operating system level” — consistent with the conventional textbook view that a single operating-system-level file-access check is regarded as adding less overhead than a DBMS separately evaluating its own stored privilege rules.

Result: Only the grant-option statement contradicts how OS-level authorization actually works, so “The administrator enjoys more control on the grant option” is the false statement.