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);wrote on 12 Oct 2018, 09:15 last edited by koahnig 10 Dec 2018, 09:34No, 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.
-
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);wrote on 12 Oct 2018, 09:19 last edited byAgree 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.
wrote on 13 Oct 2018, 00:59 last edited by JonB@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 :) ]wrote on 13 Oct 2018, 09:53 last edited by@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.
-
@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.
wrote on 13 Oct 2018, 13:38 last edited by JonB@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.
wrote on 13 Oct 2018, 18:40 last edited byWhen 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?
-
@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?
wrote on 14 Oct 2018, 10:56 last edited byCertainly 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?
wrote on 14 Oct 2018, 13:04 last edited by@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
-
@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
wrote on 15 Oct 2018, 13:16 last edited by@kshegunov Like I said: there's no "root", there is "Administrator".
11/13