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


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

Submitted by:  lar3ry gensch <lar3ry>
Submitted on:  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

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( 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>
Project 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>
Project 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>
Project 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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

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