I have been trying to add/delete local permissions for a file/folder in Alfresco using open CMIS with mix success. My tests are done on Alfresco 4.2f/5.0a with Apache chemistry CMIS 0.10 on a mixture of Windows, *nix platforms.
When adding roles to the local permissions list, I am seeing Alfresco generated roles such as All, roles.write, roles.read, etc being generated. I have been trying to clean this up through resetting the ACL after adding permissions, but with some mix success.
Secondly, when deleting the last local role from the permissions list, I notice that the inherited permissions are now made local for some reason. For instance, if the inherited permissions contained user1 as a Coordinator, this will now also appear in the local permissions list.
I understand that CMIS has some limitations with handling permissions. How do I go about resolving the things I am seeing?
Related
I have one svn repository with around 100 users having read/write access to it. Recently I noticed that some of the folks are syncing the data from this repository to their local repository using, svn sync command. This looks like a security breach and I am wondering if there is a way I can block svn sync commands from svn server side. Any help appreciated.
This is not a security breach.
The users have access to the repository and repository items with respect to path-based authorization access rules an administrator set for them. The users don't get unauthorized access to the repository unless your server is misconfigured.
I am about to embark on the development of a line of business application using the Universal Windows Platform (Windows 10). One of the requirements of the application is the synchronisation of data from a server to a local SQLite database; this is required because the application needs to be usable where there is no network connectivity.
It is likely that multiple (windows domain) users will be accessing the application on the same device, sometimes simply by "swapping users", other times by logging off the first user and logging on as a new user.
I realise that UWP applications are installed at a user level, however I would like to be able to share the SQLite database between these users instead of forcing each user to download their own copy of the data.
Is this possible? I am struggling to find any reference to this kind of sharing within the Microsoft documentation - but of course that documentation is new and far from complete!
I guess at the end of the day I am looking for access to a folder that is accessible by any user running that application on the same device, such as the "x:\Users\Public" folders that are available from the desktop, but without having to ask the user to provide access to that folder via any picker control - instead simply being able to "open" it.
Thanks.
In case anyone runs across this, this functionality is now available as described in this blog post:
We introduced a new storage location Windows 10, ApplicationData.SharedLocalFolder, that allows multiple users of one app to share local data. Obviously this feature is only interesting with devices that will be used by more than one person. For such scenarios, for example in educational uses, it may make sense to place any large downloads in Shared Local. The benefits will be two-fold: any user can access these files without the need to re-download them, also there will be storage space savings
Keep in mind that Shared Local is only available if the machine has the right group policy, otherwise when you call ApplicationData.Current.SharedLocalFolder you will get back a null result.
In order to enable Shared Local the machine administrator should enable the corresponding policy.
Alternatively, the administrator could create a REG_DWORD value called AllowSharedLocalAppData with a value of 1 under HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager
Note that data store in ShareLocal will only be persisted as long as the app is installed on the device and won’t be backed up by the system.
In Solution Explorer , Right click on Package.appxmanifest then click on ViewCode , end of this file in both projects add below code :
<Extensions>
<Extension Category="windows.publisherCacheFolders">
<PublisherCacheFolders>
<Folder Name="FolderName" />
</PublisherCacheFolders>
</Extension>
</Extensions>
After that in code you can access this folder with below line of code :
StorageFolder sharedDownloadsFolder = ApplicationData.Current.GetPublisherCacheFolder("FolderName");
It`s so important that the folder you will share between two these Apps depend on same publisher info at Certificate File [ProjectName]_TemporaryKey.pfx , if this Certificate File and publisher Info of app is same in both Projects , then you can access the same SharedFolder in both application and use it for create or use dataBase file(like SQLite Database file) or other files that need to be share in both applications.
I am building a Web Application that will be installed many times. The application needs to be able to save certain setting itself upon request.
I have an installer (InnoSetup) but I want to very careful about what permissions I give the Web Application.
I can't use a database.
A default install always leaves the web.config as read-only. (Most secure)
The registry can be problematic. Unless there is a set of keys a DotNet webapp can always write to by default (IIS_IUSR)...
I was considering App_Data, but the default permissions are no longer useful and Inno-Setup can't easily fix it correctly:
https://support.microsoft.com/en-us/kb/2005172
Security and Ease of Setup are both big issues..
I also don't want to make a mess of the machines I install to.
A FAILED solution was to write to the user portion of the registry:
Microsoft.Win32.Registry.CurrentUser.CreateSubKey("Software\\MyCo\\MyApp\\");
var reg = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\\MyCo\\MyApp", true);
reg.SetValue("MyValue", (string)dataString, Microsoft.Win32.RegistryValueKind.String);
But I found out that writing to HKEY_CURRENT_USER is also not allowed by default on Server 2012 and likely others. The server error page is helpful and gives options such as explicitly giving the IUSR_{MachineName} explicit permission but this is a no go for me.
So my final solution is to have the installer create a user configurable folder and then assigning all users Read/Write access to that folder. The administrator can always lock it down more if they want.
If anyone has a better option then let me know.
With InnoSetup I created a new Wizard page to suggest and collect a Data folder from the user. The installer then:
Created that folder and gave All Users Read/Write access,
Added a HKLM registry key telling the Web App where to look for the folder,
Notified the user that they should lock the folder down further to prevent abuse.
Hi
Im trying to find a way to recreate the all of the Roles, tasks operations etc that are currently defined in an AzMan XML store on our Dev box in an XML store on our QA box. Of course just simply copying the XML file to the QA box does not work.
Does anyone know if there is a tool to export or recreate the AzMan XML store on another machine?
thanks
Actually copping XML file from one location to another works fine. That is how we are doing right now. However copying file from one location to another location will also copy all users as well. So if you have test users defined in test XML they all will be copied to another machine.
Copying the XML file will not work IF your group assignments use different domains. Our QA box is in a different domain from our dev and production boxes, so the SIDs do not match, and, as you probably already know, AzMan uses only SIDs for assignments into groups. If everybody and all machines are in the same domain, then the SIDs won't change, and the XML store can be copied from Dev to QA.
Also, check that the permissions for your newly copied XML file on the QA box are appropriate (accessible by the process running your app, and possibly by the users running your app).
Recently I was working with generating a PDF from Crystal Reports through a webform. It was failing, which I determined to be caused by the permissions settings on the c:\windows\temp dir. I gave the Network Service account full access to this folder, which promptly fixed the issue. But is there a reason the Network Service account didn't have these permissions by default?
Rick Strahl asks this question here. It sounds like there shouldn't be any issues with doing this, but Rick wasn't clear on why the default is set that way.
Web Server is Windows Server 2003
These days, the default option will tend to be the more secure one. I don't think there's any other reason.
I've had the same issue as you, and in my environment just gave the permission and moved on.
This post suggests it is the fault of Crystal Reports, which is explicitly referencing %WINDIR%\Temp instead of using an API such as Path.GetTempPath(). In fact I have seen Path.GetTempPath() return %WINDIR%\Temp when running under the Network Service account on Windows 2003.
This post on creating temp files has comments that support using the windows temp folder.
An msdn article on using the Network Service account states that "if your ASP.NET application needs to use files or folders in other locations, you must specifically enable access" This tells me that the default restriction to the temp folder isn't because the temp folder was singled out, but that all other locations besides the IIS root folder are restricted by default.
%windows%\temp is not for general temp'ing and barfing around. It is crystal clear that Crystal Reports is abusing that directory. This happens a lot when developers are too lazy to boot up their machines with anything but an admin account.
Every user (including Network Service) has their own temp space, with full access rights, under Documents & Settings. Winners don't act like CR, and use their own temp spaces.
In short, there is nothing wrong with default permissions on win\temp. I believe it is simply meant for Windows' internal workings. (Then again, it would be much better for everyone concerned, if that directory never existed in the first place.)