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

obsolete: 8.5a5
open
Jeffrey Hobbs
2
2007-01-08
2000-10-26
Anonymous
No

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

Discussion

  • 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...

     
    • labels: 104246 --> 37. File System
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2000-11-20

    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.

     
    • assigned_to: nobody --> vincentdarley
     
  • Vince Darley
    Vince Darley
    2001-09-10

    • milestone: 102438 --> 102437
    • assigned_to: vincentdarley --> hobbs
     
  • Vince Darley
    Vince Darley
    2001-09-10

    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.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2001-09-10

    • priority: 5 --> 2
     
  • Pat Thoyts
    Pat Thoyts
    2007-01-08

    • milestone: 102437 --> obsolete: 8.5a5
     
  • Pat Thoyts
    Pat Thoyts
    2007-01-08

    Logged In: YES
    user_id=202636
    Originator: NO

    Problem still exists on Solaris 10 with tcl 8.5a5