This is an odd situation but I'm curious if anyone else has seen this behavior. We're attempting to monitor files in Google Drive in a Windows environment where the user has admin privileges. By default, when GDrive is installed the user that installed it has all READ/WRITE access.
Our application is installed as the SYSTEM user (so that it can monitor files across all users)which does not have READ access to the Google Drive folder... So we are programmatically trying to grant READ access to the GDrive folder.
When we do this as SYSTEM, I update the ACL of the GDrive folder to be set to READ for the SYSTEM user... everything looks like it should (when manually inspecting the security permissions). However, when we try and access the folder an exception is thrown (FileSystemException using the com.jniwrapper.win32.io class)
However, if I set the SYSTEM READ permission on the GDrive folder using the logged in admin user we are able to access the contents of the folder with no problem. Has anyone seen any behavior like this? Thanks.
This was resolved after looking at the formatted list of ACL permissions using this Powershell command:
Get-Acl 'C:\Users\user\Google Drive' | format-list
What I noticed when we were setting READ permission programmatically vs setting it manually is that SYNCHRONIZE AclEntryPermission was set when we did it manually. However, we did not include that permission when attempting to do it programmatically... adding that additional permission allowed us to grant READ permissions to the Google Drive folder.
Related
I'm writing an app that allows users to import their own data (via .zip's, .png's etc.) from an external location such as their downloads folder.
My app is correctly getting the file path from the URI, however I do not wish to require the WRITE_EXTERNAL_STORAGE permission in my app, which I need in order to read the file the user is providing me. I feel like Android should allow my app read permission to this file, since the user selected it.
Is there a way to have Android copy this file to a temporary location where I can read it, so that I do not need to ask the user for this permission?
If you don't want the permission, then there is a way for Android4.4 and above. Let the user import the data into the programdirectory, see also:
Starting in Android 4.4, the owner, group and modes of files on
external storage devices are now synthesized based on directory
structure. This enables apps to manage their package-specific
directories on external storage without requiring they hold the broad
WRITE_EXTERNAL_STORAGE permission. For example, the app with package
name com.example.foo can now freely access
Android/data/com.example.foo/ on external storage devices with no
permissions. These synthesized permissions are accomplished by
wrapping raw storage devices in a FUSE daemon.
Taken from this page -> https://source.android.com/devices/storage/index.html
I 've created a servlet to let users download a file . When the file is downloaded , I want it to be ReadOnly so that the user can't modify its content . So I've used the java.io.File class :
downloadFile.setWritable(false);
but I realized that the user can unset the read only flag after downloading the file .
What can I to prevent unsetting the read only flag?
I've created a servlet to let users download a file.
That servlet will be running on the web server. It's not running on the user's local computer - so it can't change anything about the user's local file system. Even your downloadFile.setWritable(false) won't operate on the user's local file system - the file will be saved by the browser, and the user gets to do whatever they want with it.
Even if you are running some app separately to your service, it would be not only hard, but pretty unfriendly to create a file which the user couldn't touch on their own system. You could try to run your app as a separate user, and give appropriate permissions to both the file and the directory it runs in - but then if the user has access to an administrator account, they'd still be able to override that.
As a user has downloaded your file, he can do anything with this file. If you are concerned about authenticity of the downloaded file, then consider data signing.
Sign your file using key, that is stored on the server and which is not available to end user.
To verify the file authenticity implement a servlet with functionality described in the link above.
I have a normal web application which are store user details and their images, we are creating user wise run time folders to store their all profile pictures.
example:- upload/user_1/anyimage.jpg
Also I have another java process(running as thread in server) which we are using to parse user data in bulk and after parsing we save it in database also we are creating run time folder to store user's profile pictures with same file structure.
example:- upload/user_2/anyimage.jpg
Now problem is:- when user 2 wanted to change their profile picture using UI(php application) using move_upload_file()
we are getting permission denied error.
When I have investigate more deeply I found that when folder has created using java application its owner is root and my php application is running under daemon user so that's the reason behind permission denied error.
How to overcome this problem, because we neither can change user who is running php application(because its system backend user) nor my java application.
As I am very new to this forum, please let me know if this is write place for this.
use chmod
chmod('/path/to/folder/, 0755);
if you want to change the ownership use:
$path = "/path/to/folder" ;
$user_name = "root";
// Set the user
chown($path, $user_name);
we are having a problem with our recently installed web app.
It allows users to upload files and save them to a directory in the OS. We've asked the Security guys to add the websphere user to the target path group, and this path has 770 permissions.
That should do it, if we log in to the machine with the websphere user, we can create folders and files in that path; but our java web app can´t create a directory and it fails.
Unfortunately no exception is thrown, the failing method first checks for this the existence of this directory with File.isDirectory() if it returns false, then it tries to create it with File.mkdirs().
The directory is not created and so a custom error message is displayed to the user. No other clue in the logs.
I've tried to reproduce the problem in my local linux laptop and toying with users and groups, i've seen that changes to permissions do not take effect until a new session is started, but i'm not sure how that affects our deployed java web app and what needs to be done for permissions to be effective.
I'm also sure the files are written with websphere user, since the app has written some files in a different path.
Has anyone faced something similar?
thanks
chown seems to be a solution.
UPDATE:
Another solution is to check the 'file permission policy' for the java client (see).
Java 2 security uses several policy files to determine the granted permission for each Java program.
For the list of available policy files that are supported by WebSphere® Application Server, see Java 2 security policy files.
* The client.policy file is a default policy file that is shared by all of the WebSphere Application Server client containers and applets on a node.
* The union of the permissions that is contained in the java.policy file and the client.policy file are given to all of the client containers for WebSphere Application Server and applets running on the node.
* The client.policy file is not a configuration file that is managed by the repository and the file replication service. Changes to this file are local and do not replicate to the other machine.
* The client.policy file supplied by WebSphere Application Server is located in the profile_root/properties/client.policy.
* If the default permissions for a client (union of the permissions defined in the java.policy file and the client.policy file) are enough, no action is required. The default client policy is picked up automatically.
* If a specific change is required to some of the client containers and applets on a node, modify the client.policy file with the Policy Tool. Refer to Using PolicyTool to edit policy files for Java 2 security, to edit policy files. Changes to the client.policy file are local for the node.
I hope it helps you.
I have a java applet that is downloaded to a user's browser when they visit a webpage and allows them resumable file uploads to my server. Obviously, this requires the applet to access the user's hard disk, which I understand is outside the regular sandbox applets can run in. The user sees a security warning popup which asks for their permission to allow this applet to run.
I have signed the applet using verisign and the link from where is applet is fetched is over SSL with a versigned cert. None of these make the warning go away.
Is there a way to make all warnings go away? Can anyone explain what is going on behind the scenes?
JNLP has a FileOpenService which allows the untrusted Java Webstart applications to show a File Open dialog to the user and access the file the user selected:
http://docs.oracle.com/javase/1.5.0/docs/guide/javaws/jnlp/javax/jnlp/FileOpenService.html
You can't avoid this message, it would be a security issue if you could.
Granting Applets Permission
If you tried to run the applet example, you undoubtedly saw errors when you clicked the Click Me button. This is because the Java 2 Platform security does not permit an applet to write to and read from files without explicit permission.
An applet has no access to local system resources unless it is specifically granted the access. So for the FileUIAppl program to read from text.txt and write to text.txt, the applet has to be given the appropriate read or write access permission for each file.
Access permission is granted with a policy file, and appletviewer is launched with the policy file to be used for the applet being viewed.
What you can do is having a configuration (a policy file) to allow this applet to use some files. But you would have to do this manually (for obvious security reasons). Check the link below.
Resources :
oracle.com - Applets, File Access and Permissions