File Permissions

jondoe

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);

koahnig

@jondoe

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.

VRonin

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

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 manipulate hosts file permissions.
And BTW: if I install your software, and I have an existing hosts file, 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

@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

@koahnig
But you said

No, 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 the setPermissions() call he is making. I'm realising now maybe that was what you were commenting on, but he needs to know about the setPermissions...

koahnig

@JonB

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.

JonB

@koahnig

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 hosts file, which surely he did intend his code to do :)

aha_1980

@JonB ... which would have been no problem, as you wouldn't have run untrusted code as root, or would you?

koahnig

@aha_1980

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

@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....

kshegunov

@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

@kshegunov Like I said: there's no "root", there is "Administrator".