Re: NTEA extensions for uid/gid

[Ronald Landheer-Cieslak <ronald at landheer dot com>]

On Mon, 27 Jan 2003, Corinna Vinschen wrote:
> On Fri, Jan 24, 2003 at 05:19:47PM +0100, Ronald Landheer-Cieslak wrote:
> > > This has nothing to do with each other.  The mount -E flag doesn't
> > > influence the permission bits.
> > Then what is it supposed to do? I mean, if the man page says it makes 
> It handles the way executables are recognized.  There's a mechanism in
> Cygwin, trying to find out whether a file is exacutable or not, regardless
> of permission settings (e.g. on FAT filesystems).  Having a .exe suffix
> is one of them.  -X treats all files as executable, -E treats no file as
> executable.  It speeds up processing of large /bin dirs etc.
Ah, OK. 

What I don't get (yet) is how come the mount table doesn't have an 
influence on the bits, as the bits are reported by stat(), stat() 
apparently uses exec_state() and exec_state() uses the path_flags, which 
is apparently "sensitive" to the mount table (seeing as it's only set/used 
in path.{h|cpp} (path_conv) and mostly in path.cpp (path_conv::check). 
Haven't looked into the details, though, so I might be missing something.

In any case, seeing the behaviour of the exec-permission bits, I have a 
"wouldn't it be nice if...": wouldn't it be nice if the executable 
permission bits would actually correspond to the executability
of a file? I mean, an explorer-created empty file is definitely not
executable - notably because it's empty.

IIRC, stat() looks inside the file anyway, so the executable permission
bit could just be set if
* the file has an executable extention and the permission bit on the file
  system (of applicable)
* the file looks executable (magic number) and has the permission bit on
  the file system (if applicable)
* the file is a directory and has the permission bit on the file system
  (if applicable)
Taking the mount table into account, of course.

The only drawback I see with a scheme like this is if someone sets the
executable permission on a file that fails the executable tests, but if
the tests are done well enough, that would only happen on files that
wouldn't really be executable anyway.

I don't think this would add a lot of overhead if stat() already looks in
the file anyway, and the checks would probably only have to take place if
we don't know whether the file is executable or not (which could be stored 
with its inode number, which is generated on-the-fly, IIRC)

I'd be happy to spend some time on patches if you and Chris think it's a 
good idea.

> > Content-Description: getfacl output
> Looks as expected.
> Thanks,
You're welcome :)

rlc



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/