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

obsolete: 8.5a5

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'

Askar Rahimberdiev

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.

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

  • Donal K. Fellows

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

  • Andreas Kupries

    Andreas Kupries - 2001-09-07
    • 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

    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

  • 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
    Originator: NO

    Problem still exists on Solaris 10 with tcl 8.5a5


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks