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