Please explain how content security works on SenseNet.
Especially how to read the following SN database view:
PermissionInfoView
What EFEntries(LocalOnly) flag is used for?
In a nutshell: it works very similarly to the file system permissions in Windows.
You can define permissions for individual users, or (more preferably) groups and org units. Defining a permission happens on a content, usually on a container like a workspace or folder. For example you give Open and Save permissions for the Editors group on the Articles folder.
There is inheritance: child content will inherit permissions you defined on the parent folder (unless it was defined as local only, which means not propagated to children). For example if you define a local only Save permission on a document library for John, he will be able to modify the doclib content itself (e.g. change its display name), but not the files inside the library.
To make things a bit more complex, you can break permissions on a content, for example to remove an inherited permission. This may be necessary if you want to hide a subfolder.
For details please visit the Permission System article.
Permission overview GUI
If you have installed the WebPages component of SN7, you get a Permission Overview page that may help you understand the current permission settings in the tree.
The Permission info database view
In case you have the Services component only (so no GUI) or you really want to look under the hood, you can check out this db view to see all the permission settings in the system.
The records here contain all the defined permission entries in the system (so inherited ones cannot be seen here, they are calculated in memory). The Path is the content where the permissions are defined, the Identity can be a user or group, LocalOnly means not propagated to children (see above), the rest is a list of permissions (e.g. Open or Save) and whether they are allowed, denied or undefined.
For details about this and other db elements please visit the DB structure article.
Related
I have some issues with the Plone 4.3.1 permission settings. But I have come long way with the existing documentation and Aspelli's book. But I cannot figure out why I am unable to create any object in a folder, even as Site Administrator, after setting up a workflow-state that grants permissions to a specific user role.
The workflow-state is called "Show_External" and the permissions that are set through the Permissions tab of the workflow state are as follows:
Permission Acquire Site Admin Ext_Supplier
Access content information - X X
List folder contents - X X
Modify portal content - X X
View - X X
I do not want to "Acquire" any permissions because the new role is for an external supplier that has no business with anything else on this particular site.
The result - much against what I expected - is that no one can create any object. The option is shown in the interface, but any attempt results in Error Please correct the indicated errors.. No errors are indicated however.
What I can do is make the objects (folders and files) in another folder and then copy paste them to the folder that is set in the workflow-state. Stranger still, once I copy the folder as a subfolder to the External Supplier folder a can add files through QuickUpload, but not by selecting "Add file".
What am I missing in my understanding of the permissions?
You likely ran into a bug, which was fixed just now:
http://plone.293351.n2.nabble.com/Bug-on-sharing-page-upgrade-plone-app-workflow-to-2-1-6-td7566655.html
Does upgrading p.a.workflow help?
The solution in the end was to install plone.app.workflowmanager. For some reason that I do not understand the "Permission Roles" that show up under the workflow states created through ZMI did not have either the "Add" or the Review Permission.
Correcting the permissions through the workflow manager solved the problems.
If you try it out then note that you need to check the "Advanced Mode" checkbox to be able to update the permission settings on existing objects.
Having dregdged through ZMI screens for the past few days, the Workflow Manager is a great improvement! Very nicely done.
If someone can still explain why there is a difference between the permissions that I set through ZMI and the workflow manager I would very much like to know (feel free to edit this answer, marked as "community wiki").
We have multiple apps that use OpenLDAP for authentication and for storing data. We have quite lot links to these OpenLDAP entities from DBs from multiple applications (each app has its own DB), so when you change OpenLDAP entity you have to track object changes (currently we are using DN as a reference key). And inside LDAP we have few references, like what user can access which objects, as they can have very specific access rights (access right are not depend on hierarchy), LDAP also doesn't track these changes, so once these referenced objects are moved we need to track them both in LDAP and in multiple DBs.
I'm new to linux and OpenLDAP (we have it running on linux), but to me this all seems like a wrong way to handle things and it seems like we are using LDAP in the way it wasn't designed to be used (The idea of using it like this came from senior developers).
My questions is:
Is there anything bad to use LDAP in way i have described.
How can i change the OpenLDAP schema to create something like GUID for all object classes we are using, this way at least we can store object GUID instead of DN and don't have to track changes. If I change schema will I be able to perform search and filter by this GUID?
Sorry, but your architecture description is not clear for me, so I can't write if it's bad to use it like this.
Having multiple directories in a company is very common in middle to big companies (most of the time it's due to historical reasons) but for single sign on "Meta directories" are setup to have a single authentification point.
In my point of view the DN is obsolutly not the way to point an object in a directory, jus because moving an object is changing his DN. Each directory has got an attribute inherited from the "top" class that contains an unique identifier inside the directory. In OpenLDAP it's entryUUID.
entryUUID: bec561c4-c5b0-102a-81c0-81bc30f92d57
If you want to link datas in a not too big Directory you can also use referential integrity, that the way users are linked to groups (when you move a user you don't have to look at each group it belongs to) in operating systems directories (RefInt Overlay in OpenLDAP).
I have multiple projects in TRAC. I'm using mod_wsgi, and my wsgi script file TRAC_ENV_PARENT_DIR variable is pointing to the folder containing folders with all these projects. A few users have access to different projects. When a user visits the TRAC URL, she can see the listing containing all these projects, yet has no access to some of them.
Is there any way to show to a user only those projects this user has access to?
Please advise.
Preamble: I abhor security through obscurity. Your request could be read as cosmetics in web site presentation. Don't aim at improved access control, because knowing a valid path will still give access to each Trac environment depending on it's settings. Of course better navigation is a good reason.
Requiring to hide folders depending on user's permission means you require authentication before granting access to TRAC_ENV_PARENT_DIR. This could be done with standard mechanisms that your web server supports. This is just the precondition.
As you say, you have some non-public Trac instances in your Trac environment folder collection. How complicated it is to identify all folders correctly, that depends on how much you want to spend on initial implementation vs. maintenance.
I should be trivial, but error-prone, to provide a list of either the public or the private directories, of course whatever is easier to maintain. Zero additional configuration would require to open each Trac environment and look up user permissions. )** This sounds rather cumbersome and means probably a performance penalty for applications with large user base and frequent access. You will at least work with a cached list, if you go down this road.
You can't use Trac's auto-generated Available projects list but you'll have to deliver at least two versions of an index page for authenticated/unprivileged and authenticated and privileged users.
For the sake of maintenability you'll want to consolitate configuration and permissions. For access to each Trac environment you could use trac.ini inheritance and a shared .htpasswd file. However you can't inherit permissions, because these settings are stored inside the Trac db. You could give TracUserSyncPlugin a shot, but it seems not yet fit for production, or at least lacks feedback of all the happy users, if they exist.
)** While I'm not aware of dedicated documentation about this, there are actually several possibilities. Since permissions are stored in the Trac db, all involve reading/querying the permission db table. It's structure is documented with all other tables of the Trac db schema. To read you'll want to open the Trac environment(s) and then use a direct query on the table (see a AccountManagerPlugin changeset for an example) or construct and query a PermissionCache object.
It may be an old question, but so far i've found the answers to be rather complex without need.
I think using the information stated here, http://trac.edgewall.org/wiki/TracInterfaceCustomization#ProjectList , one could build a template that checks for users and permissions and then show the data it should.
In my case, i just needed to point the "TRAC_ENV_INDEX_TEMPLATE" variable to blank HTML, and that was enough for me.
I'm working with Fisheye and I created a few repositories and a few projects referencing them. I want to show them to anonymous users, but although repositories are shown to anonymous users (non-registered), projects aren't.
I went to Administration, Repository Defaults, Permissions, Anonymous Access and set 'Allow anonymous access to the repositories', but how can I do the same with the projects?
The projects tab actually stems from Crucible rather than FishEye (you can have one or the other, but they run together if both are available), see the header on the project administration page:
A project is a set of Crucible content combined with a set of
customisable FishEye content.
Consequently this is a Crucible setting, which is orchestrated via Permission Schemes under Security Settings within Administration, thus a bit more complex. You'll have to review and experiment with the various permissions yourself on how to achieve the desired goal (each permission has a separate Allow Anonymous users setting), but I venture the guess that adjusting the View -
Ability to view a review. setting accordingly should be all you need.
I've been working on making my app easier to use for administrators. One of the things I'd really like to do is allow admins to modify other user's settings from within the program -- while still making it possible for regular ol' users to modify their own settings, as my application isn't necessarily only for administrators who want to force users to use specific settings.
I thought of two possible ways of doing this:
1) Move the user setting file path from where it is now (CLSID_APPDATA, commonly Documents and Settings\Username) to a world-accessible path (CLSID_COMMON_APPDATA , commonly Documents and Settings\All Users). Then, save each user's settings to a unique file for the user (probably having a name which equals that of the user's textual SID), so the folder looks something like:
C:\Documents and Settings\All Users\My Company\My Program\settings\123-abc-456-def.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\234-bcd-477-xyz.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\946-hdc-743-ddd.settings
Pros:This allows an admin to see and directly modify any user's settings, because the COMMON_APPDATA path is the same for all users. This is how I'd really like it to be -- it's the most straightforward -- but there's a major con:
Cons:Permissions could be a problem. To allow regular users to save their settings, you'd have to allow users write access to the program's COMMON_APPDATA setting folder.
Of course, when the settings are saved and the setting file created on disk, you'd want to limit write access on the user's setting file to the user who the settings are for, and for admins, so that other limited user's can't modify them.
However, it could be that before a user has a chance to write their own settings from within the program, a savvy, malicious limited user creates a setting file for that specific user, without the knowledge of the user. If the limited user creates the file, that means they own the file... and then that user (who the settings are for) can't modify the settings anymore, unless an admin changes the permissions on the file.
An unlikely situation perhaps, but it still worries me.
2) Instead of moving the setting file path to a globally-accessible path and modifying the user's setting file directly, have my app create and save an "override" file in the app's CLSID_COMMON_APPDATA folder, to allow the admin to override the user's settings.
When my app loads for that user (who's settings were "overridden") it'll detect this file and load it instead of the regular setting file, which is located in CLSID_APPDATA (Documents and Settings\Username).
Pros:Permissions are easy to deal with.
By default, for the Documents and Settings\Username APPDATA folder, only admins and Username can access the files from within. So that in itself protects the user's own regular personal settings from other limited users.
To protect the "override" settings, my app can simply deny write access to the COMMON_APPDATA folder -- where the override file is written -- to all but administrators, and then that's that. These overriding settings will only be modifiable by admins.
Cons:This method is obviously more roundabout. If a user modifies his own regular personal settings, an admin won't see those changes -- the admin can only see the settings he's overriding the user's regular settings with (which he can force the user to use instead).
In some ways, this might be good, but... the fact that it's roundabout turns me off somewhat.
I'm interested to hear what you guys think about this. Which is my best option? I'm personally leaning more towards #2, because while it's less straightforward, it seems to be more secure and isn't so roundabout where it'd be confusing for an admin.
However, I'm also open to suggestions. Is there a superior option you think would work better?
EDIT 7/6/09: I should note that for option #2, the admin could not only override all user's settings with a single override file, but also override an individual user's settings with an override file specific to that user (just like with option #1, that file name would likely be that of the SID of the user who's settings are being overridden). Not sure if that was completely clear in the original post.
Unless there is more than one user account on each computer (i.e. a computer is used by more than one person), option two is the better choice.
Even if there is more than one user account on each computer, I think option two is still a better choice. Worst case, the administrator will have to change settings on a handful of accounts on the same computer instead of one.
If your facility allows random usage of any computer by any person, then option one is the better choice, since option two will make it too difficult to maintain that many different accounts on every computer.
Of course, you can always put the application settings in user folders on the server. That would make it very convenient for an administrator.
If the administrator already has rights to the user's directory where his setting's file is stored, wouldn't that already solve your problem? Either way though, it sounds like option 2 would be best, then you could have a single file that could override say a group of users, then each user have their own settings as well. Just so long as your application is smart enough to tell when to override a setting and when not too, option 2 shouldn't be that much of an issue.