straw poll for "veto files" [was Re: "veto files" problem]

David Collier-Brown davecb at canada.sun.com
Fri Oct 26 05:04:02 GMT 2001


  Well, let's look at two things
- the costs and benefits of the specific change, and
- the cost of making a change.

1a) Right now, the benefit is that veto'd files can be
    written to but not read from (or read for execution).

    This is a useful tool for secure system's logs, and
    for school's dropboxes, although the implementation is
    not complete for either: you can't see if you've dropped
    anything in the dropbox, and you can overwrite logs you
    can't read.

    We don't know any other used for this as yet, nor do we
    have reports of it's use.

    The disadvantage is that access to these write-only files
    may come some other way. For example, if you have both 
    NFS and SMB service, a virus can write into one from
    either NFS or SMB, and a NFS-connected client can read 
    from it.

1b) If we change it, we lose the proposed dropbox and log
    capacity. The latter can be replaced with a 'sticky' 
    directory, the former by writing a vfs module.

    I therefor argue that making the change is a slight advantage
    to us, and that the disadvantages are manageable.

2)  The cost of changing it (or anything!) is that 
    people will have to 
	i. recognize something has happened
	ii. be able to judge it's value
	iii. be able to respond to it.

    We've mostly dealt with (iii) in (1b).  We can deal with
    (ii) in the release notes.  Alas, users are going to 
    discover (i) "by accident".  That's a cost, but the
    files being writeable is counterintuitive, so I suspect
    the degree of surprise will be very low.

All in all, I argue it's better to change it.  With Mr. Sorce,
I suspect we might want to be prepared to put in an option
to restore the previous behavior if we find someone using it.
I suspect #ifdefing the changes might be appropriate.

--dave
-- 
David Collier-Brown,           | Always do right. This will gratify 
Americas Customer Engineering, | some people and astonish the rest.
SunPS Integration Services.    |                      -- Mark Twain
(905) 415-2849                 | davecb at canada.sun.com




More information about the samba-technical mailing list