I'm trying to migrate my current Phabricator deployment (which is a Ubuntu VM) to a docker based container.
According Phab's documentation, I should use the following command line:
bin/config set --database repository.default-local-path /my/new/path
The command above fails with:
Usage Exception: Config key "repository.default-local-path" is locked and can
only be set in local configuration. To learn more, see "Configuration Guide:
Locked and Hidden Configuration" in the documentation.
When I try the command above without --database, it changes the local.json and successfully. However, it seems that properties in stored in DB have precedence over properties defined in JSON file. Therefore, the change made to JSON file has no effect.
If this is not a bug, how do I change repository.default-local-path? If it is bug, is there any workaround?
I don't think "locked" configuration options are ever meant to be set at the database level. This value should be provided in the local config.
Assuming that you have a value set in the database that is interfering with your local config, I'd say that is a bug. The easiest workaround that I know of is to unlock the config option by editing phabricator source. What you need to do is as follows:
Unlock the config option. To do this, change the source code from setLocked(true) to setLocked(false) on line 25 of PhabricatorRepositoryConfigOptions.php.
Set a value for repository.default-local-path in local.json as you already managed to do with bin/config set (leaving off the --database argument)
Delete the database value with the following command: bin/config delete --database repository.default-local-path
Once everything is set correctly, you can revert your change to PhabricatorRepositoryConfigOptions.php which will restore the option to the locked state.
I am building a Web Application that will be installed many times. The application needs to be able to save certain setting itself upon request.
I have an installer (InnoSetup) but I want to very careful about what permissions I give the Web Application.
I can't use a database.
A default install always leaves the web.config as read-only. (Most secure)
The registry can be problematic. Unless there is a set of keys a DotNet webapp can always write to by default (IIS_IUSR)...
I was considering App_Data, but the default permissions are no longer useful and Inno-Setup can't easily fix it correctly:
https://support.microsoft.com/en-us/kb/2005172
Security and Ease of Setup are both big issues..
I also don't want to make a mess of the machines I install to.
A FAILED solution was to write to the user portion of the registry:
Microsoft.Win32.Registry.CurrentUser.CreateSubKey("Software\\MyCo\\MyApp\\");
var reg = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\\MyCo\\MyApp", true);
reg.SetValue("MyValue", (string)dataString, Microsoft.Win32.RegistryValueKind.String);
But I found out that writing to HKEY_CURRENT_USER is also not allowed by default on Server 2012 and likely others. The server error page is helpful and gives options such as explicitly giving the IUSR_{MachineName} explicit permission but this is a no go for me.
So my final solution is to have the installer create a user configurable folder and then assigning all users Read/Write access to that folder. The administrator can always lock it down more if they want.
If anyone has a better option then let me know.
With InnoSetup I created a new Wizard page to suggest and collect a Data folder from the user. The installer then:
Created that folder and gave All Users Read/Write access,
Added a HKLM registry key telling the Web App where to look for the folder,
Notified the user that they should lock the folder down further to prevent abuse.
I need to programatically enable remote config access to various servers that do not have remote access enabled.
I need to enable remote access, read the machine.config, and disable it again.
I'm trying to use psexec as outlined in this question's answers: How to execute a command in a remote computer?
However the aspreg_iis -config+ command is returning a file not found error:
psexec \\server "c:\...Net 4 path...\aspnet_regiis -config+"
The system cannot find the file specified.
Can anyone point out what I am doing wrong here?
If this is not supported, is there another way to accomplish this?
Well that was embarrassingly simple: just omit the quotation marks:
psexec \server c:...Net 4 path...\aspnet_regiis -config+
and it works fine.
I want to invoke an updater to check for updates (not to actually do the update but only check if there is any). I would like to do this in the background and silently. If there is an update, I would ask the user for elevated permissions and run the updater with that. The checking involves reading a file in the application's directory and comparing the version found in it with the one on a website.
How can I run it without elevation for checking only? QProcess::start() fails because it needs elevated permission and ShellExecute only works if I add the "runas" verb for the same reason (which I only want if there would be actually writing in that directory i.e. I want to perform an update). I'm guessing I need to add some sort of manifest but I don't know its contents.
So it turns out that I had another bug that caused the non-elevated running branch to run in all cases. The model I described in the post works. To avoid Windows infering the need for elevated permissions, you need to add a manifest resource. (for example, if the name of your application exe contains the word "updater" it will be triggered)
The contents of the manifest are the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Compiling it to your .exe depends on your compiler and environment, so I'm only showing mine: Qt Creator and mingw-gcc:
Create an rc file for the resources with the following content:
1 24 DISCARDABLE manifest.xml
Add this rc file to your .pro like this:
win32:RC_FILE = resources.rc
After this, ShellExecute without the verb paramter will run without elevation, and using "runas" will run it with elevation.
Elevation prompt appears when your application requests it, for some reason. You can control it with the application manifest. See Create and Embed an Application Manifest (UAC) article for details on how to add the manifest.
I would suggest you the following:
Separate your Updater and Update Checker, so that they're in different .EXE files.
UpdateChecker.exe requires no administrator privileges, and thus requestedExecutionLevel element of the manifest has asInvoker level.
Updater.exe requires administrator privileges because it writes updated application file into Program Files. Therefore requestedExecutionLevel element of its manifest has requireAdministrator level.
In your program you can launch UpdateChecker.exe whatever way you like. To start Updater.exe you will have to use ShellExecute; if the application has the manifest (and I strongly recommend embedding manifest) it will show UAC prompt for elevation if the application wants administrator privileges. There's no need to use runas verb.
Alternatively you can check whether update is available or not from your main application. And launch the Updater.exe only when there's a new version on the server.
Another option would be to make Updater.exe both check for update and apply it if there's one, just like you do it now. In this case Updater.exe should have asInvoker level in its manifest. When it starts, without parameters, it checks whether there's a new version on the server. If it finds newer version, it re-launches itself with administrator privileges and passes a command-line parameter, for example /doUpdate, which instructs it do perform the actual update.
In order to re-launch itself elevated, it has to use ShellExecute function and runas verb, because ShellExecute will be unable to detect automatically your Updater.exe now requires administrative privileges.
Keep in mind that the meaning of runas verb differs between Windows XP and Windows Vista/7, so you should handle this situation if you want to support previous versions of Windows. The first approach I described will work on Windows XP without additional handling.
I suggest to use one of these scenarios:
put that file in user's profile instead of application's path
copy content of that file to user's profile in case of it's in read only mode then run QProcess::start()
include that file inside .qrc file then extract it to user's profile in case of failing of read or run QProcess::start()
I have a SQLite database that I am using for a website. The problem is that when I try to INSERT INTO it, I get a PDOException
SQLSTATE[HY000]: General error: 8 attempt to write a readonly database
I SSH'd into the server and checked permissions, and the database has the permissions
-rw-rw-r--
I'm not that familiar with *nix permissions, but I'm pretty sure this means
Not a directory
Owner has read/write permissions (that's me, according to ls -l)
Group has read/write permissions
Everyone else only has read permissions
I also looked everywhere I knew to using the sqlite3 program, and found nothing relevant.
Because I didn't know with what permissions PDO is trying to open the database, I did
chmod o+w supplies.db
Now, I get another PDOException:
SQLSTATE[HY000]: General error: 14 unable to open database file
But it ONLY occurs when I try to execute an INSERT query after the database is open.
Any ideas on what is going on?
The problem, as it turns out, is that the PDO SQLite driver requires that if you are going to do a write operation (INSERT,UPDATE,DELETE,DROP, etc), then the folder the database resides in must have write permissions, as well as the actual database file.
I found this information in a comment at the very bottom of the PDO SQLite driver manual page.
This can happen when the owner of the SQLite file itself is not the same as the user running the script. Similar errors can occur if the entire directory path (meaning each directory along the way) can't be written to.
Who owns the SQLite file? You?
Who is the script running as? Apache or Nobody?
For me the issue was SELinux enforcement rather than permissions. The "read only database" error went away once I disabled enforcement, following the suggestion made by Steve V. in a comment on the accepted answer.
echo 0 >/selinux/enforce
Upon running this command, everything worked as intended (CentOS 6.3).
The specific issue I had encountered was during setup of Graphite. I had triple-checked that the apache user owned and could write to both my graphite.db and its parent directory. But until I "fixed" SELinux, all I got was a stack trace to the effect of: DatabaseError: attempt to write a readonly database
This can be caused by SELinux. If you don't want to disable SELinux completely, you need to set the db directory fcontext to httpd_sys_rw_content_t.
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/railsapp/db(/.*)?"
restorecon -v /var/www/railsapp/db
I got this error when I tried to write to a database on an Android system.
Apparently sqlite3 not only needs write permissions to the database file and the containing directory (as #austin-hyde already said in his answer) but also the environment variable TMPDIR has to point to a (possibly writable) directory.
On my Android system I set it to TMPDIR="/data/local/tmp" and now my script runs as expected :)
Edit:
If you can't set environment variables you can use one of the other methods listed here: https://www.sqlite.org/tempfiles.html#temporary_file_storage_locations
like PRAGMA temp_store_directory = 'directory-name';
In summary, I've fixed the problem by putting the database file (* .db) in a subfolder.
The subfolder and the database file within it must be a member of the
www-data group.
In the www-data group, you must have the right to write to the
subfolder and the database file.
####### Additional Notes For Similar Problem #####
I gave write permissions to my sqlite database file to other users and groups but it still didn't work.
File is in my web root directory for my .NET Core WebApi.
It looked like this:
-rw-rw-rw- 1 root root 24576 Jan 28 16:03 librestore.db
Even if I ran the service as root, I kept getting the error :
Error: SQLite Error 8: 'attempt to write a readonly database'.
I also did a chown to www-data on the librestore.db and I still received the same error.
Finally I moved up above my webroot directory and gave others write access to that directory (LibreStore - the root of my WebApi) also and then it worked.
I'm not sure why I had to give the directory write access if the specific file already had write access, but this is the only thing that worked.
But once I made that change www-data user could access the .db file and inserts succeeded.
I got the same error from IIS under windows 7. To fix this error i had to add full control permissions to IUSR account for sqlite database file. You don't need to change permissions if you use sqlite under webmatrix instead of IIS.
I used:
echo exec('whoami');
to find out who is running the script (say username), and then gave the user permissions to the entire application directory, like:
sudo chown -R :username /var/www/html/myapp
(For followers looking for an answer to a similar question)
I'm building a C# .Net Core 6.0 WPF app. I put the Sqlite.db3 on the c:\ drive for convenience while developing. To write to the database I must open Visual Studio 2019 as Administrator.
#Charles in a comment pointed out the solution to this (or at least, a botch solution). This is merely me spelling it out more clearly. Put file_put_contents('./nameofyourdb.sqlite', null); (or .db, whichever you fancy) in a .php file in the root directory of your app (or wherever you want the db to be created), then load that page which renders the php code. Now you have an sqlite db created by whichever user runs your php code, meaning your php code can write to it. Just don't forget to use sudo when interacting with this db in the console.
A good clean solution to this is to allow the file of your main user account to be written to by (in my case) the http user but this worked for me and its simple.
None of these solutions worked for me and I suppose I had a very rare case that can still happen. Had a power shortage so even with 777 permissions on folder and db file, without SELinux, I would get this error.
Turns out there was a jellyfin.pid file (not sure if it's named after the service or user as they have the same name) locking it after the power shortage. Deleted it, restarted the service and everything worked.
I got this in my browser when I changed from using http://localhost to http://145.900.50.20 (where 145.900.50.20 is my local IP address) and then changed back to localhost -- it was necessary to stay with the IP address once I had changed to that once