bugvile, a vi-compatible text editor - Bugs: bug #28639, Check for "insecure"...


bug #28639: Check for "insecure" file seems too broad on OS X

Submitter:  lar3ry gensch <lar3ry>
Submitted:  Sun 17 Jan 2010 06:40:19 AM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Fri 09 Apr 2010 02:23:02 PM UTC, comment #6: 

Verified on Mac OS X 10.6.


lar3ry gensch <lar3ry>
Fri 09 Apr 2010 08:48:09 AM UTC, comment #5: 

I addressed this in 9.7za:

 20100128 (za)
        + add "always" setting for check-access mode, to distinguish between
          scripts and datafiles, e.g., tags.  Use "always" to check permissions
          for data.

Thomas Dickey <dickey>
Group administrator
Sun 17 Jan 2010 03:54:12 PM UTC, comment #4: 

It is - but I'm missing something.

To try to see what you're talking about, I configured
vile using --with-trace, and used this for my .vilerc:

setv $shell=/bin/sh
store-procedure gimme
        ~force edit-file &cat "!gzip -dc " "/usr/build/vile/vile/testing/CHANGES

where I'd made the testing directory and its contents all 0777.
The .vilerc is outside the testing directory.

I can read the file (as expected) on Linux, but the trace doesn't
go into bind.c's check_file_access function.  I had in mind to
see how it was being called, but it's not - in my quick test.

(I didn't use the vileinit.rc, etc. in the test since the
trace does get large - but the settings might be relevant).

Thomas Dickey <dickey>
Group administrator
Sun 17 Jan 2010 02:39:19 PM UTC, comment #3: 

Pardon my ignorance, but isn't check-access supposed to be used for checking file permissions before sourcing it into a script?

The script is successfully sourced.

The problem is that the script, once sourced, fails on the following line:

    ~force edit-file &cat "!gzip -dc " %zfile

Apparently, the check-access value is being used when a file (pipe) is being EDITED, not sourced.

This very script works on other systems.  I figure you don't have a Mac for testing (no Mac GUI version--pity!), but I'd be willing to help diagnose things if you can point me in the correct direction.

lar3ry gensch <lar3ry>
Sun 17 Jan 2010 11:43:14 AM UTC, comment #2: 

Perhaps what changed was the way OS X reports
status for pipes.  I can see how someone might
argue that since ultimately the source of the
pipe was world-writable data, so stat() should
tell the same story.

Is this case covered by changing the
check-access mode to none?

Thomas Dickey <dickey>
Group administrator
Sun 17 Jan 2010 06:42:40 AM UTC, comment #1: 

Additional info:  vile-9.7z

lar3ry gensch <lar3ry>
Sun 17 Jan 2010 06:40:19 AM UTC, original submission:  

For some reason, a vile script I use quite a lot stopped working on my OS X system.  I had to turn on $debug and tracing to figure out that an attempt to read a gzipped text file was failing with an warning that it was insecure (and the error was that the file was world-writable).

The file exists on a FAT volume mounted on my OS X system.  Therefore, all files seem to have a mode 0777 (world writable).

The interesting thing was that the "file" I was editing was actually a pipe (remove the quotes):  "!gzip -dc 195/19531.gz" (the file is a gzipped text file; archived mail file).

I thought that vile is supposed to consider data read from a pipe as read-only... but the complaint is that it's world writable... very weird!

The comment in bind.c seems to indicate that the check is for a file "sourced" on a Unix system; having it world or group writable can indeed be a security risk.  However, this code is being checked during a pipe read.

To get around this problem, I simply commented out the check for world-writable and group-writable in bind.c.

I think this "security check" should be better thought out.

The script is simply allowing me to view an archived email message.  Is this no longer allowed?

lar3ry gensch <lar3ry>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #19500:  gzip-script.txt added by lar3ry (1KiB - text/plain - Script that fails on read from gzip file)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by dickey (Posted a comment)
  • -email is unavailable- added by lar3ry (Submitted the item)
  • -email is unavailable- added by lar3ry

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-28 dickey StatusNone Fixed
    2010-01-17 lar3ry Attached File- Added gzip-script.txt, #19500
        Carbon-Copy- Added lar3ry

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code