File Permissions
-
Hello,
I want create hosts file and permissions should be like nobody cant delete this hosts file and nobody cant edit this hosts file.
I creating new hosts file with this codes. When I creating with this code I cant edit but I can delete.
I want that nobody connot write, read, delete.How can I do this ?
QString filename="C:\\Windows\\System32\\drivers\\etc\\hosts"; QFile file( filename ); if ( file.open(QIODevice::ReadOnly | QIODevice::Text) ) { file.write("test"); file.close(); QFile(filename).setPermissions(QFile::ReadOwner);Agree with @koahnig this is a task for the file manager, not the application.
I would be afraid of an operating system that allows an app to do this.
Even using your example, a malicious software could change the file hosts to redirect web requests to different sites than the legit ones. The user can't be locked out of those files forever -
No, these gives only the permissions for the your application internally.
http://doc.qt.io/qt-5/qfile.html#setPermissions says:
Warning: This function does not manipulate ACLs, which may limit its effectiveness.and ACLs are https://en.wikipedia.org/wiki/Access_control_list
AFAIK you need to do it externally, but I might be wrong.
@koahnig said in File Permissions:
No, these gives only the permissions for the your application internally.
Don't know what you mean by this?!
Anyway: https://code.woboq.org/qt5/qtbase/src/corelib/io/qfile.cpp.html
218 Qt's understanding of file permissions is limited, which affects especially
219 the \l QFile::setPermissions() function. On Windows, Qt will set only the
220 legacy read-only flag, and that only when none of the Write* flags are
221 passed. Qt does not manipulate access control lists (ACLs), which makes this
222 function mostly useless for NTFS volumes@jondoe
Forget trying to manipulatehostsfile permissions.
And BTW: if I install your software, and I have an existinghostsfile, and your installer replaces my file, unless you own my machine I shall be very cross with you.....
[Thankfully, your existing code will fail to do that, probably unintentionally :) ] -
@koahnig said in File Permissions:
No, these gives only the permissions for the your application internally.
Don't know what you mean by this?!
Anyway: https://code.woboq.org/qt5/qtbase/src/corelib/io/qfile.cpp.html
218 Qt's understanding of file permissions is limited, which affects especially
219 the \l QFile::setPermissions() function. On Windows, Qt will set only the
220 legacy read-only flag, and that only when none of the Write* flags are
221 passed. Qt does not manipulate access control lists (ACLs), which makes this
222 function mostly useless for NTFS volumes@jondoe
Forget trying to manipulatehostsfile permissions.
And BTW: if I install your software, and I have an existinghostsfile, and your installer replaces my file, unless you own my machine I shall be very cross with you.....
[Thankfully, your existing code will fail to do that, probably unintentionally :) ]@JonB said in File Permissions:
@koahnig said in File Permissions:
No, these gives only the permissions for the your application internally.
Don't know what you mean by this?!
When you open a file read-only in your app, you have only ready-only rights until you change it. However, it does not have any effect on ACL represented by your OS.
Vote the answer(s) that helped you to solve your issue(s)
-
@JonB said in File Permissions:
@koahnig said in File Permissions:
No, these gives only the permissions for the your application internally.
Don't know what you mean by this?!
When you open a file read-only in your app, you have only ready-only rights until you change it. However, it does not have any effect on ACL represented by your OS.
@koahnig
But you saidNo, these gives only the permissions for the your application internally.
What does "internally" mean? Yes, going
QFile(filename).setPermissions(QFile::ReadOwner);does not touch the ACLs in the filing system. But it does touch the Windows "read-only" flag on the file in the filing system. That's not "internal", it's just as "external" as altering ACLs would be.When you open a file read-only in your app
That would refer to where the code goes
file.open(QIODevice::ReadOnly | QIODevice::Text), but the OP is asking about thesetPermissions()call he is making. I'm realising now maybe that was what you were commenting on, but he needs to know about thesetPermissions... -
@koahnig
But you saidNo, these gives only the permissions for the your application internally.
What does "internally" mean? Yes, going
QFile(filename).setPermissions(QFile::ReadOwner);does not touch the ACLs in the filing system. But it does touch the Windows "read-only" flag on the file in the filing system. That's not "internal", it's just as "external" as altering ACLs would be.When you open a file read-only in your app
That would refer to where the code goes
file.open(QIODevice::ReadOnly | QIODevice::Text), but the OP is asking about thesetPermissions()call he is making. I'm realising now maybe that was what you were commenting on, but he needs to know about thesetPermissions...You got a point there. However, I did not go as far down in the code.
When you open a file with ReadOnly, which may be successful as tested, you cannot write to it.Thanksfor correcting my view.
Vote the answer(s) that helped you to solve your issue(s)
-
You got a point there. However, I did not go as far down in the code.
When you open a file with ReadOnly, which may be successful as tested, you cannot write to it.Thanksfor correcting my view.
When you open a file with ReadOnly, which may be successful as tested, you cannot write to it.
Yes, we are fortunate this is in the OP's code, as it has stopped him overwriting the content of my
hostsfile, which surely he did intend his code to do :) -
When you open a file with ReadOnly, which may be successful as tested, you cannot write to it.
Yes, we are fortunate this is in the OP's code, as it has stopped him overwriting the content of my
hostsfile, which surely he did intend his code to do :)@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
Qt has to stay free or it will die.
-
@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
Certainly he would as long as he is good Windows citizen and he is doing also what those helpful MS guys calling you midday to clean out your security issues ;)
Seriously, I got 6 calls recently within 2 hours. They were really concerned about my well-being respectively of my computers. I can't believe that they realy can make money with that, obviously it is doing fine enough. Unfortunately, I am not 100% sure that we are immune to attacks.That is what is most worrying.
-
@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
@aha_1980 said in File Permissions:
@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
There's no "root" in Windows :) The last time I looked, I had no trouble writing to
C:\Windows\System32\drivers\etc\hosts. Plus, I thought this might be being done as some kind of "installation" phase, so maybe running elevated anyway.... -
@aha_1980 said in File Permissions:
@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
There's no "root" in Windows :) The last time I looked, I had no trouble writing to
C:\Windows\System32\drivers\etc\hosts. Plus, I thought this might be being done as some kind of "installation" phase, so maybe running elevated anyway....@JonB said in File Permissions:
There's no "root" in Windows
oh, but there is, it's just called "administrator". It's unfortunate (or fortunate) that most people run their windowses (like I do) as "power user", otherwise it'd be quite unusable ;P
Read and abide by the Qt Code of Conduct
-
@JonB said in File Permissions:
There's no "root" in Windows
oh, but there is, it's just called "administrator". It's unfortunate (or fortunate) that most people run their windowses (like I do) as "power user", otherwise it'd be quite unusable ;P
@kshegunov Like I said: there's no "root", there is "Administrator".
