[Dev-luatex] file permissions

Reinhard Kotucha reinhard.kotucha at web.de
Mon Feb 7 01:41:09 CET 2011

On 6 February 2011 Hans Hagen wrote:

 > On 6-2-2011 3:56, Reinhard Kotucha wrote:
 > > $ whoami
 > > reinhard
 > > $ ls -l /etc/passwd
 > > -rw-r--r-- 1 root root 2269 Dec 19 14:57 /etc/passwd
 > >
 > > Your test suggests that the file is writable, but this is only true
 > > for root, not for the user who is running the script.  You actually
 > > have to determine whether you are the owner of the file, or, if the
 > > file is group writable, whether you are member of this group, or
 > > whether the file is writable by everybody.
 > Isn't it a bug in the lfs library then? When is the point in returning 
 > an attribute that has no defined meaning?

No, it's not a bug.  The name "attributes" is misleading, "stat" would
be better.  It *has* a defined meaning, it just returns what's stored
in the stat structure of a particular file:

  struct stat {
        dev_t     st_dev;     /* ID of device containing file */
        ino_t     st_ino;     /* inode number */
        mode_t    st_mode;    /* protection */
        nlink_t   st_nlink;   /* number of hard links */
        uid_t     st_uid;     /* user ID of owner */
        gid_t     st_gid;     /* group ID of owner */
        dev_t     st_rdev;    /* device ID (if special file) */
        off_t     st_size;    /* total size, in bytes */
        blksize_t st_blksize; /* blocksize for file system I/O */
        blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
        time_t    st_atime;   /* time of last access */
        time_t    st_mtime;   /* time of last modification */
        time_t    st_ctime;   /* time of last status change */

This is exactly the information you see in directory listings.

lfs.attributes supports the stat() system call directly, except that
st_blksize and st_blocks are not defined on Windows and that st_mode
is split up into "permissions" and "mode".

 > > Regarding Windows, I'm not sure.  As far as I can see from the
 > > Lua sources, permission flags are directly derived from a stat()
 > > call.  This means that they are related to the file owner too,
 > > not to the current user.
 > I suppose that we're only interested in the current user, so
 > lfs.attributes should return the user's attributes. I was always
 > under the impression that this was the case.

I think that lfs.attributes is correct, despite its unfortunate name.
I proposed lfs.access() because access() and stat() are two distinct
system calls anyway.

 > > If there is a file which is owned by the admin and is _not_
 > > writable by normal users, does your test really return 'false' if
 > > run by a non-privileged user on Windows?
 > I don't know. Whatever we end up with it should be robust or at
 > least predictable.

I think that what I proposed is reliable and relatively easy to
implement.  At least there is an access() function in MSVCRT too which
does the same as the one on Unix, though the executable bit is ignored.  

   if lfs.access(file, 'rx') then ...

should be as robust and predictable as 

   if (-r $file && -x $file) { ...

in Perl.


Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the dev-luatex mailing list