Just a note: SCCS does not intend to exactly reproduce the
permissions of a file. It just likes to permit a user to make
a script executable in order to be able to check it.

BitKeeper SCCS does include support for reproducing arbitrary
permissions but this is not really compatible with the ideas
of SCCS. Future versions of SCCS may incluse some kind of similar
support.

The man pages of the original SCCS have been rewritten to include
more information. This includes previously undocumented feaatures
that some people may rely on. I recommend you to have a look at
the SCCS man pages at:

It's least astonishing for us to treat execute bits as we do read bits; if the umask permits, the gotten file is world-readable; the previous mode of other files doesn't affect it. Hence if the history file is executable it's least surprising for the gotten file to be mode 0777 (modified by the umask). This is the Solaris behaviour.

Setting world-execute permissions on the gotten file is unlikely to grant additional access to anybody since (subject to umask) they can read the gotten file anyway (hence copy it and chmod it themselves).

I'm inclined to implement the feature, but closely following the behaviour of Solaris 10 in particular (I didn't check other versions) may not be the best approach, since that implementation somewhat violates the principle of least astonishment:

When reading the input file (named via admin -i, for example) only the owner's execute permission bit is significant. The setting of this bit is copied however to all three of the execute bits in the history file [note 1] if the input , and in turn that is copied to the mode bits of the subsequent gotten file.

The result is that you take a file executable by owner only, check it into SCCS, check it out again, and suddenly it's world-executable (depending on your umask).

[note 1]: I assume this happens because the history file and the gotten file are created with mode 0666 (if the original file was not owner-executable) or mode 0777 (if the original file was not owner-executable).

An "sccs create myfile" command, where myfile had execute permissions beforehand, destroys those execute permissions. This is an inappropriate intrusion, and does not mirror the behavior of standard SCCS (e.g., on Solaris). Standard SCCS copies the execute permissions to the SCCS/s.myfile file, and does not remove them from the original file.