AmazeFileManager
AmazeFileManager copied to clipboard
TeamAmaze
Unable to Modify Permissions (Interface Missing)
First off, let me say I like the look and feel and looking forward to it being a real competitor to Root Explorer (UX is atrocious) and ES Explorer (bloated approaching malware status) they just destroyed it with crap - any company installing their own SU whether you are rooted or not and bypassing your system is not my idea of legitimate or trustworthy. So take what I am about to say in the spirit of caring and genuine inquiry, not complaining.
Is this seriously missing the ability to manage permissions or am I missing something? Seeing permissions is not as helpful as actually being able to do something with them. This ability is one of the most basic and core functionality of any File Explorer, especially if they are providing "root" option. This should have literally been one of the first 5 things to put in a file manager.
I mean what exactly is the app doing with root permissions that it can't provide the basic permission change? Using root access just for basic rwx functions seems a great and utter waste of that option. It would be the equivalent to having a super computer to check email or read news :)
I really want to like this app, the interface is glitchy but clean enough, I like it - even if the focus is on looks rather than function. The functionality is the part that is lacking, beyond the basic view/copy/move/create, I mean any app does that, even the built-in browser on Android does that (not well but again, why did IE win so long? it was there and worked). So to have this overhead installed, you have to get some extra benefits from it, so far doing a decent job (like the SMB, which only a small comparative portion of the users need - I use, so thank you - or the FTP - even I don't find use for that) but the lack of this ability (which 99% using a file manager on rooted Android do in contrast) makes ZERO sense in a world where managers are becoming just me toos :/
Any thoughts on this? preferably from people who actually work with the code like the developer(s), not spectators guessing or making assumptions. Thank you in advance and keep up the good work, hoping for meaningful productive discussion, so don't just add noise.
Some thoughts looking at this : File object, we already have some set* methods that will handle quick permissions without resorting to FileUtils reflection for the time being. Specifically: setReadable, setWritable, and setExecutable. This would be a stopgap measure to provide the functionality while a more robust system is put in place to handle more than just basic setting to include other ownership flags too down the line. It also adds little to no overhead since the File object is already a core reference being used (from the quick look at the code).
Take care.
Enable root explorer from settings, and open properties of any root file. You should be able to see permissions option.
I have root option enabled and I do look at the properties and all it has are copy link and open that's it. Nothing to do with permissions there, so perhaps the implementation is failing?
Perhaps next time you can be sure the problem is resolved before closing it prematurely. It doesn't help anyone to show so little consideration. Clearly it wasn't there if a professional couldn't find it. So maybe ask what went wrong.
Properties Name ... Location /... Size of Folder ... Date ... md5: ... Cancel | Copy MD5 | Copy PATH
No permissions.
I'm sorry. I meant in no way to offend you. The permission button appears only when it is allowed for the file to change the permissions i.e. when permission chars are greater than 6. You should try viewing properties of a root files instead of flash storage (which is accessible by everyone).
@vishal0071 I wasn't offended, just surprised about the assumption and the fact that you are equating is-there+works-4me to nothing wrong with it.
1st. Doesn't matter the size of the file, the length of the filename or anything, it won't show up period. I know you mean the length of the "permission string" and the way you are parsing them now is indicative that you are putting the restriction in there based on the method you are using.
2nd. Doesn't matter if it is on internal storage or external (in my case not a real external it is emulated and resides in the same place as any other file - like every other Nexus user) only separated symbolic link.
3rd. When you are rooted it matters not where the file is, you have access and can modify it, period; but even with that consideration, it won't show on any other file location either. SO clearly, not the only issue.
So what now? Clearly the implementation is failing. Possibly due to the SU app you chose to build upon (which is?), where is the code that handles this so I can see why it is breaking; since you don't seem to want to deal with making it work right and the app shows up on the SU log but shows that all it does is send the command exit nothing else. That is when it IS sending something, the rest of the time it is just blank, meaning you are not sending commands or correctly. I have spent time trying to locate your implementation here but so far all I see in the code are parsing for showing permissions, so if you can point me to it, that would greatly save time.
Also permission changes are universal, you should in no way be the decider as to what file the person interacts with on the system, the feature is the feature, how it is used within it's capability is strictly a user choice. Unless you want a niche app that only works for certain files and in which case this will not be usable for any professional who is doing anything serious or important then. If your implementation is causing the limitation, then you are doing it wrong and should change it, not say this is it - right? I am trying to help resolve it but your resistance to it seems illogical to me.
What is the environment? Android version, phone model, useful additional information.
@EmmanuelMess at this stage shouldn't matter but you are right, I should have included that prophylactic for the heck of it, since we seem to be grasping at everything EXCEPT the problem :)
Nexus 6 (Shamu) Android 7.1.1 (official stock) Rooted
anything else to be added to the "useful additional information" that I missed?
Here's the link to the properties dialog (line 701). 2,3. User mounted filesystem (SD Card, Emulated Storage) are accessible by everyone and changing permissions doesn't matter there. BTW are you able to see permissions when you enable show permissions option from settings? (A screenshot would be helpful)
I am having problems rooting an android 7.1.1 emulator, so I can't test.
Testing on emulator doesn't make sense. @EmmanuelMess how would you root it?
@vishal0071 thank you for the link, allow me to lighten my desk a bit and I will dive into it soon.
As far as I know, any file accessible to the system can be restricted via permissions, regardless of where they are located logically, physically they are the same. I will look into it again to confirm.
Yes, when selected to show permissions (which I already had) it DOES show the permission string, yes. I would be happy to provide a screenshot, but allow me to do it in a bit when I am at my desk.
@EmmanuelMess I am sorry to hear that, I know there have been issues with that, we have been lucky to have access to TWO units, one from the initial release (hw) and the second from the "post battery drain" era release (hw) so we have been able to test a lot of things first hand which is nice. Emulators are awesome when they work though.
Additionally, as vishal pointed out, it wouldn't do much good to "root" something that has no physical access, ergo no selinux style enforcement, forgive me if I am wrong but that is how it was explained to me back when it was still gingerbread ;)
Thank you for the effort though.
Ok, just thinking out loud here, can't we change this code to something like this:
if(root) {
try{
appCompatButton.setVisibility(View.VISIBLE);
appCompatButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (permtabl.getVisibility() == View.GONE) {
permtabl.setVisibility(View.VISIBLE);
but.setVisibility(View.VISIBLE);
setPermissionsDialog(permtabl, but, hFile, perm, c);
} else {
but.setVisibility(View.GONE);
permtabl.setVisibility(View.GONE);
}
}
});
}catch(e){
// maybe perm.length()<6 or something else
// we add a graceful handler to do what you are doing now
// with the character limitation, this way you are behaving more
// like a firewall rule ... allow what you allow and catch the rest
}
}
Right now you are neutering it by casting a really wide net and that's not necessary - IMHO; this way you allow the routine to try and show the interface and continue with the function.
If it encounters an error then you know you hit that <6 condition (which I still don't understand why it matters to you), then do at that point what you do NOW and gracefully continue.
It may not look like the prettiest thing but the fact is that it will be far more efficient, like sometimes needing a catch all so you can hit a few condition and let the rest drop.
For performance sake - because sometimes processing power is cheaper than the memory cost of carrying extra baggage - so this way you shift the balancing toward the CPU which is negligible here.
In my humble opinion, letting a try/catch block handle the valid parts and bypass the exception is a much more stable implementation, even if a bit "hacky".
Thoughts? I'd happily be a guinea pig and test it out to work through the logic if you can build it for me, as I am not setup with a compile environment where I am, to do it myself.
Have a good night everyone and as promised here is a screenshot for you.
*clearly the permissions are less than 6 characters but it should not matter*
I think Exceptions should not be used in normal execution; I also don't understand why it is using the length, as it should always be the same (because of the -'s). Shouldn't the letters be compared by position to r, w, or x instead of using the length?
Creating views for something that's not really there will probably lead to NPE. If you do a quick stat -c %a (path to storage) you'll see the permissions are in form XX0. The last zero is what bothers us as permissions start with atleast 1. This and the fact that permissions can't be imposed on user space leads us to hide us the Permissions button, and check for the same by not accepting length less than 6.
Ps. on some file system the length is 3, so anything less than 6 is not compatible with linux style permissions.
@EmmanuelMess exactly, that was my point, the character length didn't make any sense to me either so I was hoping to understand that myself as well.
@vishal0071 shouldn't you be doing an octal evaluation to begin with? that would make the character count moot? Also, Android's implementation of Linux is not entirely the same as the distro Linux and permissions is one aspect that is NOT the same in Android Linux vs. Traditional Linux. Please look into that, it was something even I wasn't aware of until comparatively recently myself.
I'm talking about octal notations only. We can't possibly have 0 in octal notation. BTW why are we even discussing this, it's working fine for you, right? In your screenshot the Permissions button is clearly visible, and I hope permissions are changing fine for you.
There are absolutely no permissions access in the screenshot. Show me where you would click to change the permissions? Permissions translate to 0+i(rwx)i(rwx)i(rwx), for example 0644 and that's what matters, not anything else you are talking about in regards to how you are relating the length of the string to the value of the string.
There are clearly no parsing errors from your screenshot. In your screenshot you are not even in root folders, go to root folders to see the permissions button, then press on that button to see all the checkboxes. Also, confirm you're using the latest Amaze version 3.1.2 beta 9. The implementation is absolutely fine.
@vishal0071 You are right about shared storage — most modern Android devices use FUSE on top of FAT/VFAT for external SD cards, and that combination does not support changing file permission. But files in that filesystem still has Unix permissions, they are just hardcoded and changing them fails without any effect.
It is probably a good idea to show the option to change permissions anyway. There are a lot of different devices out there, you can never be sure, what is supported and what isn't. In the worst case chmod might fail to change the access rights, no harm done.
Could you just start with empty permissions when the current permission string can not be parsed?
@vishal0071 you are equating showing permissions to being able to change them, they are NOT the same thing, so while you are showing permissions - fine, that is completely irrelevant to being able to set/change them, which you are not showing and the screenshot supports that.
The fact that YOU are choosing to prevent access to certain files based on completely arbitrary reasons is the problem and insisting about /root only makes you look bad because IT IS ON THE ROOT, the fact that they might also be accessible through symbolic links doesn't change the fact that they are ON THE "ROOT" and therefore subject to permission NO MATTER where they are. Especially if the device is rooted.
@Alexander-- correct that permissions on "removable" drives are subject to a different set of overlaying permissions; however, it is not applicable to any device that has no PHYSICAL sd card (the reason why most - not Samsung - have gone the "emulated" way), that was something introduced to repair the clusterf**k that followed changes in 4.x (second update KitKat) but that does not automatically mean that permissions are irrelevant and cannot be set; that is complete fallacy as nothing on a Linux system is exempt from permissions; not just them, ANY OS. The only people still pushing the flawed physical sd card implementation are Samsung and they are doing it because it is their only shtick and those who realize it is utterly useless, would stop using it (the "feature" I mean). App2SD was supposed to take some of the pain out but that failed to persist due to the erratic changes that were introduced since KitKat that pretty much made it a hacky work around, more so than it already was.
Proposed solution: If for whatever reason, given the method used to parse them, they don't show, exactly set what you have and leave the rest empty until give a parameter to set, well said Alex and I can see that being a very useful modification.
Thank you vishal for changing it, I appreciate that and I will test it heavily to ensure that we don't cause more problems and that it gracefully handles any "challenges" that might come up due to DEVICE variance, not necessarily the Android variance. And an answer to an earlier question, yes I am using the latest available version for Amaze, I wouldn't even bother wasting anyone's time, including my own, unless I was on the latest build, otherwise any discovery is moot and useless.
Have a good day everyone, back to the grind :)
@vishal0071 in Android, permissions have an extra bit at the beginning for ID, which associates it to the user/group/other (hence the 3 boxes below it) so 666 is not the same on Android as it is on Linux, usually it will be 0666 in Android, because of the additional bit, or if running in a different context then could be 2.
You can take a look here for more explanation of it. summary before you dive into the dry and extensively convluded documentation that Google has at developer.android.com, hope it helps.
Guys let's not have a fight here. I was a bit annoyed with the subject of this issue at first but we clearly need a much cleaner permissions tab. I am already working on new properties UI. It's sort of a bottom sheet, and will have permissions as a standalone tab with other tabs like to generate digests. As for this extra bit for permission, I don't think it's of any use. Any linux package like chmod, stat gives permissions in form of xxx in output rather than xxxx, even in android. So I don't think it's practical to support anything that's actually not there at all. Not sure why CM has it.
@vishal0071 don't worry, no fight. I provided the information believing the person is serious to learn, I was wrong, so as such I wished them well and moved on :) That doesn't constitute a fight, thicker skin my friend.
I am sorry it was an uncomfortable topic for you but I am hoping that now you can see that it was meant with love and intended only to improve things; hindsight right? While for most people the standard permissions will do, do not discount the important of the owner IDs, that can cause real issues if it is changed improperly but how you implement it is up to you.
They have it because they want people to be able to set permissions correctly and in one shot, not have to set the owner id first and then issue the permission change, it would be very inefficient. Perhaps considering UX, they felt it was important to provide a complete solution. To clarify, most of the time whatever the ID is, changing the permission alone will not break anything, but if you change permissions that require specific context, then if you don't account for that, it WILL break things.
It is a quite old issue but
Here is a detailed explanation of Android file système for /sdcard, /storage, data/media and so on: https://android.stackexchange.com/a/205494/249916
If stack' s response is not satisfying enough, the Android documentation is also presenting the situation: https://source.android.com/devices/storage/config.html
Here is some commands examples:
Trying in sdcard
Trying storage
Trying data/media
Sdcard after data media
Thus, we can modify the true file (data/media) for the linux system, but the fat virtualization does not propagates rights for all users. (Security concern presented in above links)
So @Alexander-- gives hints with FUSE/FAT. @gsantner is right to says:
can try it: try adb shell ; chmod 777 /sdcard/somefile.txt and see yourself, that the file will stay at his permission (on most devices).
@GuardianMajor is also right to say:
something introduced to repair the clusterf**k that followed changes in 4.x (second update KitKat) but that does not automatically mean that permissions are irrelevant and cannot be set
I see 3 options:
-
If we want to fully modify permissions in
/sdcardand/storageas asked by @GuardianMajor , this should be done by tweaking the sdcard emulation. But this may be far beyond the scope of this application and may be more for a custom ROM or an advanced magisk mod. -
Under the hood magic, by resolving real path for emulated cards and settings permissions for
ownera'ndgrouponly. -
Display an error message for
/sdcardand/storagewith a link to a FAQ explaining the situation and the current possibility to partially modify under/data/media.
Would direct interaction via C with the kernel, using the "real" path (not simulated) for files, be a solution for this?
I would like add a feature request in this thread for permissions. It would also be convenient if we could, in addition to changing rwx attributes, also change the process (/pid) or the user defined as Owner or group like some explorers allow us to.
