#559 Ability to auto-set/inherit permissions for a whole category


I'd like to be able to create a category and define
default permissions for it and any objects within the
category. I'd also like to be able to define
permissions as "default" for any future objects added
to a category.

Example: I'm currently configuring a network
monitoring/management system (Nagios) for work. It has
a handy place to specify a URL with additional info
about the specific host in question. There can (and
will) be hundreds, or even thousands of these.

Tiki seems like an obvious place for putting these
pages. And the group-editing/permissions functions make
this a great way for an entire team of IT staff to
collaborate as well as correct/update data as time passes.

However, this data may conceivably contain information
not for general consumption, such as IP addresses,
server notes, customer information, passwords, etc. It
should be visible to the group responsible for using
those pages (in this example, some group of IT folks,
but not necessarily all of the IT staff) and not to
others that may also use the Tiki, such as others in
the same department, other departments, customers,
general users, etc.

Thus, it would be extremely useful to be able to set
permissions for an entire category, and all objects
within it, and to optionally set permissions (possibly
different ones) for all future objects added to this

Having to remember to add permissions on a per-page
basis (and even then, only after that page has been
added and saved into the Tiki) is both tedious, and
prone to errors and accidents. It will almost certainly
become a security liability/nightmare if sensitive
(i.e. - useful) information is stored in there, because
someone is bound to forget to add proper
permissions/restrictions to a page, or some other user
may see the new page pop up in something like the "Last
Changes" module and click on it during the 30-60
seconds before the page author gets a chance to click
over and change the permissions on the newly-created page.

Obviously, categories should not even be
visible/browse-able by people without the proper
permissions. Otherwise, they might become even *more*
curious about it. Also, the Category listings
themselves would have to be restricted to somewhat
bland-sounding and non-descriptive names, and any
summary-notes as well, to avoid attracting undue
attention from other Tiki users.

A (possibly useful to staff) descriptive comment of a
change might say "Updated passwords for this host" (or
worse yet, list the password, or say that a password is
weak and should be changed on a specific host) and thus
give would-be attackers a head-start and area to focus
on. Conversely, a non-useful (but more secure) comment
line might say "Minor updates", or say nothing at all,
making it harder for staff to locate the appropriate
page if needed in the future. Hiding these from
unprivileged people at the start would avoid these

Otherwise, future authors would be forced to be mindful
about keeping their Subject and Comment lines
nondescript and bland, lest they give away sensitive
info. (Bound to cause problems...You can bet money on
it.) Hiding these sorts of things from unprivileged
users from the very start would avoid problems like this.


A category called "CustomerInfo" might be a place where
individual items are kept with sensitive info such as
customer name, phone number, address, Tech-Support
notes, IP addresses, and possibly (depending on how
much people trust the Tiki permissions system) even
passwords, billing/payment info and history, credit
card info, etc. -- In other words, all the sort of
information that they might be keeping elsewhere in a
database. Perhaps even the same MySQL database that the
Tiki resides in. It seems natural to want to integrate
that data into the rich features that Tiki offers
without having to duplicate it among several
data-stores. (I, for one, hope to be able to do that,
eventually.) -- However, customers themselves might
think it's the proper place to create their personal
web pages, and even log a Support Request when they get
an error saying they don't have permission to
view/edit/etc. objects in the "CustomerInfo" category!

This confusion could be avoided if they aren't allowed
to see that the category even exists in the first place.


There are also some irregularities/bugs with the
permissions system in general, and with categories in
particular, and I've filed separate bug reports for
those. But for completion's sake, I'll list them
quickly here and you can route to the appropriate
people if you wish. (Search for my name under
'submitter' in Security Bugs to see the full
descriptions of these.)

Some things I've noted so far:

-- tiki-browse_categories.php allows users to see
number of objects, type (i.e. - Wiki page) and name of
the object, even if permissions on that page are set so
they cannot view the page in question.

-- The same holds true for tiki-listpages.php


    • milestone: 316040 --> 316042
  • teedog

    • milestone: 316042 --> New_Feature
    • priority: 5 --> 7
    • assigned_to: nobody --> teedog
  • teedog

    Logged In: YES

    I agree that Tiki should be able to assign permissions to
    categories. Since categories can contain different types of
    tiki objects, like forums and galleries, I think category
    permissions should start with simple access permission. I'm
    not sure what to do about other permissions like upload,
    lock, undo, rollback, etc.

  • teedog

    Logged In: YES

    Category permissions has been implemented in 1.9 cvs.
    Currently only tiki-index.php checks for category
    permissions until the feature has been more thoroughly tested.