#1272 [file executable file_name] always returns 1 when working fr

[Anonymous]

OriginalBugID: 5859 Bug
Version: 8.4a1
SubmitDate: '2000-06-08'
LastModified: '2000-07-25'
Severity: MED
Status: Assigned
Submitter: techsupp
ChangedBy: ericm
OS: Solaris
OSVersion: SPARC Solaris 2.6
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Askar Rahimberdiev

ReproducibleScript:
When working from root account, [file executable file_name] command always returns 1 disregarding actual file permissions (for any existing file). However, subsequent exec command will fail if file has no execute permission.

DesiredBehavior:
Check file permissions using stat() (not access()) system call.

Verified on Linux and Solaris.

- eric

-- 07/25/2000 ericm

[Donal K. Fellows]

Why is Solaris claiming that files are executable (via access()) when working as root? Isn't this a Solaris (or filesystem) bug? Mind you, a file can be unexecutable (due to a bad Magic Number) even if it has the appropriate execute bits set in its file mode; [file execute] cannot ensure that an [exec] won't fail due to non-executability...

[Jeffrey Hobbs]

This has nothing to do in particular with Solaris. This is a valid stupid feature according to the POSIX spec. From the spec:

"Some historical implementations of access() do not check the file's access correctly when the real user ID of the process is the superuser. In particular, they indicate that the file may be executed without regard to whether the file is executable. The standards allow this behavior."

Thus, we shouldn't rely on access() for executability when the user is root.

[Vince Darley]

Logged In: YES
user_id=32170

This bug will also impact the behaviour of glob when asking
for executable files only. This means any fix should
change the following too (in tclUnixFile.c):

((types->perm & TCL_GLOB_PERM_X) &&
(access(entryPtr->d_name, X_OK) != 0))
)) {
typeOk = 0;

since a 'stat' buffer has already been filled in and is
available to this block of code, the change should be
easy. I leave this to Jeff on un*x to create and test a
patch.

[Pat Thoyts]

Logged In: YES
user_id=202636
Originator: NO

Problem still exists on Solaris 10 with tcl 8.5a5