attachments1Add my vote for this tag security1Add my vote for this tag create new tag
, view all tags

Move attachments out of Pub

If TWiki is to be entrusted with the Corporate knowledge base (AttachmentsUnprotectedByReadAccessRestriction) it must be capable of SecuringAttachments and it must do this by default.

TWiki's pub directory is being used for two distinct purposes: attachments (which should be authenticated) and public stuff like icons (which should not).

Attachments are data. They should be served by viewfile.

In Edinburgh and beyond I suggest we target this as a goal.

-- MartinCleaver - 12 Oct 2005

Still the material in pub should be uploadable and accessable like attachments.

Perhaps attachments can have a setting "public/private" checkbox that determines where the attachment is stored: private attachments stored in /data.

Changing the public state of the attachment moves the attachment from one dir to the other.

-- ArthurClemens - 12 Oct 2005

It's not that hard to have attachments served by viewfile, but there is a performance price to be paid.

-- RichardDonkin - 13 Oct 2005

Would viewfile mean that every attachment is secured? So images won't display when not logged in?

-- ArthurClemens - 13 Oct 2005

A short-term interim solution is to have:

  • pub/TWiki unsecured,
  • pub/icn unsecured, and
  • pub/every-other-web/ secured.

Then the performance hit is purely checking .htaccess or httpd.conf.

Material that is in pub but not associated with a topic is not currently uploadable.

Long term attachments do not belong in pub. They should be subject to access checking, with the access checking determining whether the user can view them.

-- MartinCleaver - 14 Oct 2005

From an implementation perspective, this issue is my biggest concern and I think Martin is on the right track from my view. Attachments of any type to a user created topic should be subject to access control. Common images/files should be handled separately.

Perhaps it could be a config option whether to use viewfile or not if the admin is more worried about the performance hit and they don't have a security concern.

The 'interim' solution aboive is good and similar to what we do, but it would mean that any user registered on the Wiki installation could get any document if they knew the name. Regardless of whether they had access to the web or not. It is better, but still not suitable for 'sensitive' information.

-- JohnGeorges - 14 Oct 2005

The problem with martin's proposal is ...

  • ... Per Web logos - see LogoPerWeb
  • ... embeded graphics
  • ... development

Its perfectly reasonable to have per web logos or graphics that are embedded in a topic. The copyright logo embedded in the TWiki.WebHome is an example of this. Per web logos and web support graphics would be attached to the WebPreferences topic of each web.

Other examples where the attachements need to be accessible to everyone, registered or not, include

The better solution is to - somehow - have the attachments meet the same access requirements as the topics they are attached to. That would address JohnGeorges' issue.

But for a corporate setting we need to go one step further.

When attaching a document the user will have the ability to over-ride the access control, makeing the attachement:

  • Follow the access control of the topi, even if that changes
  • Have specific access control
    • Add/Edit a DENY list
    • Add/Edit a ALLOW list
  • Have access control over who can change the access control.

The latter begs another question. I've long ago suggested moving the access control out of band. (DatabaseForPreferences, about the Evils of In-Band Acccess Control and Benefit of Out-of-Band Access Control at DatabaseForAccessControl, and of course MetadataSucks)

Why, you say? Because so long as access control is in-band anynoe who can edit tihe topic can change the access access control. This is is flagrant conflict with just about every other commercial access control system I know of and a serious problem in a corporate setting. As such, TWiki would not pass requirements for Sarbanes-Oxley or Basel-2 audits.

-- AntonAylward - 14 Oct 2005

In regards to LogoPerWeb - the variable is simply set to a URL that points to an image - the image could be located anywhere at all and is not an attachment to a specific topic - it could be attached to a publicly viewable topic.

In regards to the other topics you mentioned, in those instances the images are attachments to those topics - they only need to be viewable to people who can view that topic, as is being proposed. If someone did want to use one of those logos as a site-wide, they could copy the image to another location on the TWiki server, or attach it to a publicly viewable topic.

In essence I think you are in agreement with Martin's opening remarks to which I was referring as being on the right track.

In regards to out-of-band access-control, I completely agree in principle, but I think further discussion of the specifics is outside the scope of this topic.

-- JohnGeorges - 15 Oct 2005

John: the problem is that 'may', 'can', 'could', 'should' and 'will' are often in conflict in a Real World&tm; situation.

User001 will have a reference in TopicA to an image that is attached to TopicB and he does have permission to read both topics and hence attachments, but that doens't mean User002 does.

We normally attach logos to the WebPreferences topic for convenience. But sometimes I put generic stuff "out of band" in %PUBURL% or %PUBURL%/%WEB% which is perfectly reasonable under the present scheme and has the advantage that no-one can fiddle with it unless they have command-line access. Martin has no policy for this kind of thing and the mechanisms so far do not consider them.

Also, I realise in my editing of my earllier comment I droped why OOB Access Control has to be part of this.

  • Suppose you have a topic that is readable by two groups of users. Regardless of who can edit it, we may imagine a business requirement that only some of the attached documents are readable by the second group. If this is to work there needs to be per attachment access control and it must not depend - except for inheriting defaults on creation - on the access control settings of the topic.

Yes, there are workarounds, like having two topics, one for each group, with the headaches of syncrhonising them and duplicating some attachments and keeping them in sync too. On top of which this is a TWikiGeek solution and would be unnatural to most normal users.

OOB Access Control may be out of scope here for discussion, but the operation of controling the protection of attachments is predicated on it.

As far as ageeing with Martin - sort of. When he says "If TWiki is to be entrusted with the Corporate knowledge base it must be capable of SecuringAttachments and it must do this by default" he leaves a lot open to ambiguity. If I view this with my critical faculties turned on I as oppsed to in PHB-mode I realise its close to marketing speech. The "capable" and "default" could be taken to mean "If TWiki is to be entrusted with the Corporate knowledge base it must have a mechanism for SecuringAttachments and that mechanism must be enabled so that it follows the access controls that are set up at the web and topic levels for viewing, altering, moving and making further attachements that might potentialy overwrtie exisitng ones." That would be agood starting point.

MartinCleaver: Yes, but that's what I meant
AntonAylward: The why didn't you say that?

It doens't take much imagination to see how various programmers would implement Martin's origianl "idea" quite differnently and quite posibly break even existing systems. I've seen engineers interpret ECMA, IETF RFCs, and many others in conflicting manners. Look at the way various browsers interpret the W3 standards.

I've spent the last few months testing Dakar. Its become very clear to me that there are good reasons you don't have the programmers test their own code. They only test for what they think the code they wrote should do. I test for what I think it should do, for all the variations that I think an reasonable user might think it should do, for the variations I think an unreasonable user might imagine its supposed to do. I then see if it does what the documentation says it should do, what reasonable or unreasonable users might interpret the documentation as saying it should do - and remember many TWiki users are not native English speakers and programmers write notoriously bad documentation.

It could be worse. During WW2 the USA and the UK were both manufacturing microwave wave-guides for radar. The two sets of parts didn't fit. Now that shouldn't be possible because for any single frequency the mathematics determines the height and width of the guide. But one country took that as the inside dimension and the other as the outside dimension, since it wasn't in the formal spec. One of them was wrong because of the physics of electrical conduction it has to be the inside. But the metal foundries making the things weren't staffed by "microwave usability experts" and so interpreted it to what they thought it meant. The delay cost lives.

Its not enough that a specification for this is worked out; it must fulfil business needs. It must be flexible enough to fulfil a wide variety of business needs, and in discussion with Martin on IRC and seeing comments in Codev its clear I can see situations that he hasn't. At the very least this has to address both intranet and Intranet use; some companies will wnt to use TWiki as a portal for things like telecommuting workers, VAR channels, CRM. I can imagine uses related to handling of things like medical information, where the doctor(s) may need a restricted/protected facility but patients might have a legal requirement to see abstracts and summaries of their records. Since I'm invovled in regulatory compliance and auditing I can see - do see - many situations where there is a complex set of access requrements needed for document management.

"Do Good Stuff" and "Make it So" are great for PHB's. We need more than that. Lets start with some "Use Cases".

-- AntonAylward - 16 Oct 2005

I might have less experience with Twiki then others here, but perhaps I can add some useful observations based upon a real corporate installation of Twiki.

We are using Twiki to support both basic research here and as a Administration tool, in what will likely be a replacement for our internal web pages, to supply announcements, information, forms, and so forth. Research and Administation (including IT support) have some difference in approach, but have common security requirements placed on the information contained in the various Topics.

We need to support Access Control on Webs associated with a given Research Project, Management Function, or Administration Function. Information ranges from public domain to proprietary. Access is given to individuals or groups. We need to authenicate based upon a Unix/Linux scheme such as NIS or LDAP.

In these base requirements Twiki works well for us when used with security enhancements like PerlAuthenHandler Apache::AuthenNIS. With respect to attachments, the current work around of pub/WEB/.htaccess is usable but unsatisfactory due to the high overhead of maintaining user lists in the .htaccess files.

I am very much interested in seeing attachments in pub/ be subject to the same access control as in data/. I have no objection to a performance penalty for accessing information that is marked as restricted. I agree that it is good to have "pub" open to allow faster resolves of graphics, so clearly another container is required.

One possible solution would be to maintain a directory "priv" and add a check-box to the attach function that decided where the information will be stored "pub" or "priv". The default value on the button could be selected based upon the ALLOWWEBVIEW or some other attribute. (i.e if non-null, select "priv") A relocation tool (pub-to-priv or priv -to-pub) would be useful, but not required.

Note that fine granularity access control (AntonAylward) is useful, but less important then web-level access control. Perhaps these changes can be made in multiple stages?

-- BillKanawyer - 31 Oct 2005

For attachments we could even use finer authentication control by setting rights per attachment.

-- ArthurClemens - 03 Nov 2005

While fine-grained access control is going to be needed, a default is important. If the users are overwhelmed by detail, security is getting in the way of them doing their job and they will bypass it.

We have the default of web-level access control that can be overridden on a per-topic basis - for topics. If users can get their heads around that, then these defaults make sense, as in:

  • If I allow someone access the topic then they should be able to access the attachment
  • If I deny someone access to the topic they shouldn't be able to access the attachment

The only shortcoming with this is if there are documents at different security levels attached to the same topic.

As has been mentioned, a solution to that is create a new topic at a different security level for those other topics.

Personally, I think that most business users who demand attachment security will be satified with that. It won't be difficult to omplement.

Its the exceptions we have to deal with, and that is what I meant when I discussed specifications above, not merely granularity.

One exception is ths perfectly reasonable business situation where there is a a topic that can be edited, its attachement read, but not altered by removal or overwriting. This would be a case of Arthur's 'right per attachment'.

Starting with the 'easy stuff' as Bill suggests will be of benefit, a sales point for business applications, and should not preclude a later development, perhaps as a plugin, for fine grain control.

But I imagine the user interface will be a killer.

-- AntonAylward - 03 Nov 2005

Stores need somewhat of an overhall.

Initially I suggest moving attachments into data into a unified data-attachment directory hierarchy.

-- MartinCleaver - 03 Nov 2005

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2005-11-26 - MartinCleaver
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.