I have a dbus server publishing some methods started as root.
When I try to access it with a small python client I can't access it until I start the client as root too.
How can I have access as system user to the D-Bus service started as root ?
I asked this question due to a lack of experience and knowledge of D-Bus.
In my case I was using the SessionBus to publish my methods. As the name suggest it's a session related bus.
Basically if I start the D-Bus service with my session (my user) then my user can access it.
What I need in my case is to use the SystemBus.
From documentation (http://dbus.freedesktop.org/doc/dbus-specification.html#introduction):
D-Bus is designed for two specific use cases:
A "system bus" for notifications from the system to user sessions, and to allow the system to request input from user sessions.
A "session bus" used to implement desktop environments such as GNOME and KDE.
I have the same problem. I'm fighting against the .conf files in /etc/dbus-1/system.d but the documentation is the worst thing ever I had read:
http://dbus.freedesktop.org/doc/dbus-daemon.1.html
I think that your problem can be solved configuring your bus. Right now I have that config file:
<policy context="default">
<allow send_interface="org.company.mybus"/>
<allow receive_interface="org.company.mybus"
receive_sender="org.company.mybus"/>
</policy>
With that I can instance the bus but when I call the exported method initial_sync_data, that exceptions appears:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied:
Rejected send message, 3 matched rules; type="method_call", sender=":1.254" (uid=100108 pid=5632 comm="python applet_quota.py ") interface="(unset)" member="initial_sync_data" error name="(unset)" requested_reply="0" destination=":1.253" (uid=0 pid=5603 comm="python main.py ")
Related
This probably isnt an issue with SiteCore per se but I've included it for completeness. I have sitecore 6.3 running under IIS7 using a custom identity for the app pool. I cant get Sitecore to write its logging information (using the default log4net settings) to the eventlog. I've followed the advice here: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? and although it works fine when I make the custom identity a member of the administrator's group I need to find a way to get it working in production without such a security hack.
The weird thing is that I have a MSI that installs it (running under an account which IS a member of the administrator's group) and creates the correct registry keys in the eventlog for me and yet despite that, I am still getting the following error when I run the application using the custom identity (without it being a member of administrators).
log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.
Thinking I could narrow it down to a registry permission issue I granted Everyone full permissions to the following registry key and subkeys but it didnt work either: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
The custom identity is a member of the following groups:
Event Log Readers
IIS_USERS
Performance Monitor Users
I've also seen the following question which seems to ask the same thing. The Microsoft article seems to suggest it might be a problem with ACLs on an event log and gives examples on how you can change SSDLs but I'd rather avoid that if at all possible.
EDIT:
I have another server running where the log is being populated fine. The custom identity was a member of administrators so I revoked that and rebooted, trying to purposely break it but I cant. Config is identical on both boxes and same identity used to run the MSI which creates the registry keys. Have run procmon on both (after doing a IISReset and spinning up the app pool again) to examine registry activity. Strange thing is - on the box that works you get 477 name not found records for my event source in the wrong places (Application, and a different Custom EventLog "MyCompany"). No hits for the place where it is logging which is "MyCompany\MyCompany.SiteCore". Whilst on the box which is broken, it does appear to be requesting to read the right key (albeit only 6 times) but you then get the Log4Net registry access error.
As I understand it EventStores are stored in the registry, so you only need write permission to registry to create or delete an EventStore. This is usually only needed once and most applications create this as part of the install procedure so that the application does not need to be run as Administrator during normal execution.
However your error message (in the question) includes the method DeleteEventSource from which I would deduce/guess that the EventSource does exist but is wrong in some way. So perhaps this is currently registered as writing to the event log named MyCompany and you are now trying to change it to "MyCompany\MyCompany.SiteCore" which requires you to delete the old eventsource and create a new one.
So it sounds like your installation routine is creating a different EventSource from the one that your application is actually using.
If that doesn't help, then I would suggest enabling internal logging for Log4net (but obviously not to the eventlog) which will probably give you more information.
Giving full permission to the registry key is not enough.
According to Microsoft
To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges.
The reason for this requirement is that all event logs, including security, must be searched to determine whether the event source is unique. Starting with Windows Vista, users do not have permission to access the security log; therefore, a SecurityException is thrown.
Starting with Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. To execute the code that accesses the security log, you must first elevate your privileges from standard user to administrator. You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.
I think, contrary to the Apache documentation, log4net DOES need write access to the registry – or at least it does in my case. To prove this, I backed up the registry on the server where it wasnt working and granted IIS administrator privileges before spinning up sitecore. Sure enough it started logging away to the eventlog nicely and then when I exported the registry again to run a diff, there WAS a difference.
The value for the eventlogmessage file on my event source had been updated from:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
To
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
So I assumed that merely changing this value in the registry by hand would work.
But it didn’t.
So I ran procmon on the two servers I have: A=the working one, B=the failing one. Sure enough, on server B I have a line which says:
Operation: RegOpenKey, Path: HKLM\System\CurrentControlSet\Services\EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.
I’ve traced through with Server A and in exactly the same place, the key is requested with Desired Access:Read.
Conclusion:
It seems unavoidable that I will need to grant my app pool identity administrator privileges in production for at least enough time to programatically do the necessary registry writes the first time from within log4net. I dont know why administrator; I have tried granting Full permissions to the entire eventlog node in the registry for my custom app to no avail. It seems to do something which I cannot identify or pin down. I will then revoke this privilege immediately after it starts to log and monitor whether subsequent installs knock out the functionality afterwards. (Hopefully not).
If anyone has any insight into this behaviour it would be greatly appreciated.
When I try to execute an orchestration with something like EventLog.WriteEntry("MyEsb", "Msg"); in Expression shape, I get the exception The source was not found, but some or all event logs could not be searched. To create the source, you need permission to read all event logs to make sure that the new source name is unique. Inaccessible logs: Security. Why?
I'm running Win 7 64bit if this makes any sense.
When you write the event log from any application, the event source needs to be already created, or the application itself will try to create it before writing to it. Unfortunately, creating an event source is an action which requires local admin priveledges.
So you can do two things:
pre-create the event source
make sure the user which your biztalk host is running as is in local admins (bad)
To pre-create the event source is a nicer option. You can do this via the powershell command
New-EventLog -LogName "Application" -Source "MyEsb"
Might seem like I'm stating the obvious but has the BizTalk User got permission to write to the Eventlog? That is, the account of the Host Instance running the Orchestration.
You'll probably find that it hasn't.
HTH
Finally I've found a solution. As the error says, "To create the source, you need permission to read all event logs to make sure that the new source name is unique. Inaccessible logs: Security." So even though BizTalk User account has enough rights to write to the eventlog it has no rights to read EventLog\Security log as stated here in a Note in the Remarks section:
The reason for this requirement is that all event logs, including security, must be searched to determine whether the event source is unique. Starting with Windows Vista, users do not have permission to access the security log; therefore, a SecurityException is thrown.
So I just granted a Read Access to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Security for BizTalk User and the problem was solved.
I have a flex application that communicates via BlazeDS with two webapps running inside a single instance of Tomcat.
The flex client is loaded by the browser from the first webapp and all is well. However on the initial call to the second webapp the client receives the following error:
Detected duplicate HTTP-based FlexSessions, generally due to the remote host disabling session cookies. Session cookies must be enabled to manage the client connection correctly.
Subsequent calls to the same service method succeed.
I've seen a few posts around referring to the same error in the context of two flex apps calling a single webapp from the same browser page, but nothing which seems to help my situation - so I'd be very grateful if anyone could help out....
Cheers, Mark
Three potential solutions for you:
I found once that if I hit a remote object before setting up a messaging channel then the CientID would get screwed up. Try to establish an initial messaging channel once the application loads, and before any remote object calls are made.
Flash Builder's network monitoring tool can cause some problems with BlazeDS. I set up a configuration option on application load that checks to see if I'm in the dev environment (it is called just before setting up my channel from #1). If I'm in dev, I assign a UID manually. For some reason this doesn't take well outside the dev environment... been awhile since I set it all up so I can't remember the finer points as to why:
if (!(AppSettingsModel.getInstance().dev))
FlexClient.getInstance().id = UIDUtil.createUID();
BlazeDS by default only allows for a single HTTP session to be setup per client/browser. In my streaming channel definitions I added the following to allow for additional sessions per browser:
<channel-definition id="my-secure-amf-stream" class="mx.messaging.channels.SecureStreamingAMFChannel">
<endpoint url="https://{server.name}:{server.port}/FlexClient/messagebroker/securestreamingamf"
class="flex.messaging.endpoints.SecureStreamingAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
<idle-timeout-minutes>0</idle-timeout-minutes>
<max-streaming-clients>10</max-streaming-clients>
<server-to-client-heartbeat-millis>5000</server-to-client-heartbeat-millis>
<user-agent-settings>
<user-agent match-on="MSIE" kickstart-bytes="2048" max-streaming-connections-per-session="3" />
<user-agent match-on="Firefox" kickstart-bytes="2048" max-streaming-connections-per-session="3" />
</user-agent-settings>
</properties>
Problem: Duplicate session errors when flex.war and Livecycle.lca files are hosted in separate JVMs on WebSphere Server.
Solution:
Inside the command file for the event, set FlexClientId to null in execute method before calling remote service (Java method or LC Process).
Guess this approach can be used in other scenarios as well to prevent Duplicate session errors.
EventCommand.as file
—————————–
import mx.messaging.FlexClient;
//other imports as per your code
public function execute(event:CairngormEvent):void
{
var evt:EventName = event as EventName ;
var delegate:Delegate = new DelegateImpl(this as IResponder);
//***set client ID to null
FlexClient.getInstance().id = null;
delegate.functionName(evt.data);
}
I am getting this error while connecting to IBM MQ. I know that this is because of privileges, but is there any way just to check the connection with IBM MQ?
Please suggest.
The 2035 suggests that your connection is getting to the QMgr. If you had the wrong channel name, host or port you would get back a 2059. The 2035 means that the connection made it to the listener, found a channel of the name that was requested and attempted a connection.
If you want to test past this point it will be necessary to either authorize the ID that you are using to connect or to put an authorized ID in the MCAUSER attribute of the channel.
For a detailed explanation of how the WMQ security works on client channels, see the WMQ Base Hardening presentation at http://t-rob.net/links.
If you enable authorization messages then the 2035 will show up in the event queue. Then you can look at the message and see what ID was used to connect and what options were used too. The 2035 might be because you asked for set authority on the queue manager or something else you aren't supposed to have. The authorization messages wil show you that.
You can also resolve this By setting mcauser('mqm') .. i was able to overcome 2035 error.
Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)
Esp thanx to my SENIOR Bilal Ahmad (PSE)
You have to check the privileges with an MQ administrator.
You can use dspmqaut to check the grant.
Below is the sample to give user poc access to Queue Manager QM1 and Queue LQ1
# check the access right of user POC to QM1
dspmqaut -m QM1 -n LQ1 -t q -p poc
# if you want to give access, you should use
setmqaut -m QM1 -n LQ1 -t q -p poc <access Types>
# eg (put everything - in the real live scenario, choose only what you want to grant) :
setmqaut -m QM1 -n LQ1 -t q -p poc +put +get +browse +inq +set +crt +dlt +chg +dsp +passid +setid +setall +clr
Then dont forget to restart QM1 with
endmqm -i QM1
strmqm QM1
Finally, you should be able to proceed without error 2035.
I have been struggling with this for ages too. Eventually I found this solution. (If you can call turning off authentication a solution.)
I am using version
- IBM Websphere 9.1.0.201807091223
From IBM's website they advise turning connection authentication off!!!
Resolving the problem Disable channel authentication
You will need to disable connection authentication, at least
temporarily. There are known issues in FTM for Check with regard to
using MQ connection authorization. These problems are actively being
addressed and fixes will appear in a future fix pack. The target is
fixpack 3.0.0.8.
Steps to disable connection authentication: Open MQ command console
and type runmqsc ALTER
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS)
CHCKCLNT(NONE) CHCKLOCL(NONE) Restart the queue manager for this
change to take effect.
Source http://www-01.ibm.com/support/docview.wss?uid=swg21962081
On this topic if you are using MQSeries 9.1 in a test or development environment you can disable channel authentication with the following approach :
. Launch MQ command line utility with the following :
runmqsc (for example runmqsc QM1)
. Disable authentication for all channels with the following command
ALTER QMGR CHLAUTH (DISABLED)
For a Q/Q-manager running on Windows, you may have to create the user on the Q/Q-manager machine [i.e. create a user on the Q-machine to match the user on the Q-client machine], and then add that user to the 'mqm' group on that machine.
Steps:
Ensure that the domain user that is being used to create the Q CLIENT [i.e. the user that the Q-client app is running under] also exists on the box with the Q/Q-manager. You may be able to just create a local user on the Q/Q-manager box [, or you may have to do some more complicated creation of an Active Directory user - I can't help you there].
On the Q/Q-manager box, add the user you have just created [or the existing one, if it already exists] to the mqm group. [On a Windows server box you will need to use the Microsoft Management Console (1. 'mmc' from the command line, 2. File > Add/Remove SnapOn > Local Users & Groups, 3. add user to group)]. The 'mqm' group should already exist on the Q/Q-manager machine.
Error MQRC 2035 basically means that your application has been able to connect to the queue manager, however due to certain absence of permissions/authorizations, it was unable to put/get/publish/subscribe messages.
To resolve this, at first, try these steps in order to disable the authorizations from queue manager and channel. Use this only if it isn't a production queue manager.
Always check the queue manager logs. It tells you exactly where you need to look into, and resolve the issue.
In this case, generally, you can issue the following commands after doing a runmqsc on the queue manager :
ALTER QMGR CHLAUTH(DISABLED)
Then set the chckclnt object(under authinfo) to optional
DISPLAY QMGR CONNAUTH
DISPLAY AUTHINFO(name-from-above) ALL //name from the first commands
ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
SET CHLAUTH('*') TYPE(BLOCKUSER) ACTION(REMOVEALL)
This helps remove any blocks that the channel is creating against any user.
SET CHLAUTH(your channel name) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL)
This should resolve your issue, since we have disabled every authorization that an application has to pass in order to do anything on a queue manager.
Now, in case you are using a production queue manager, NEVER remove authorizations.
Go, and right click on any QM that you have configured in your MQ explorer. Go to the QM authority, and authority records. Click on create new user, and give the same name as the username your application is using. Select all the checkboxes, then copy from the space below all the commands that are given. Namely, setmqaut. Edit with your queue manager name, and issue them!
----Never give up, the answer is where you have not looked yet--------
Our site is currently having this problem. Basically it only happen when we click some particular links where it will pop-up a new window.
This is the error message we receive :
Unable to make the session state request to the session state server.
Please ensure that the ASP.NET State service is started and that
the client and server ports are the same. If the server is on a
remote machine, please ensure that it accepts remote requests by
checking the value of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection.
If the server is on the local machine, and if the before
mentioned registry value does not exist or is set to 0, then the state
server connection string must use either 'localhost' or '127.0.0.1' as
the server name. target site : Void
MakeRequest(StateProtocolVerb, System.String, StateProtocolExclusive,
Int32, Int32, Int32, Byte[], Int32, Int32, SessionNDMakeRequestResults
ByRef)
this is the webconfig that contain sessionstate tag :
<sessionState mode="StateServer" timeout="45" />
I have check the ASP.NET State Service, and it is currently started and set to automatic
I have set the registry stated in the error message to 1, but still not working.
Start–> Administrative Tools –> Services
Right-click on the ASP.NET State Service and click “start”
Additionally you could set the service to automatic so that it will work after a reboot
If you need to change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection to 1, remember to restart the ASP.net state service after you change the parameter.
Check that:
stateConnectionString="tcpip=server:port"
is correct. Also please check that default port (42424) is available and your system does not have a firewall that is blocking the port on your system
Type Services.msc in run panel of windows run window. It will list all the windows services in our system. Now we need to start Asp .net State service as show in the image.
Your issue will get resolved.
One of my clients was facing the same issue. Following steps are taken to fix this.
(1) Open Run.
(2) Type Services.msc
(3) Select ASP.NET State Service
(4) Right Click and Start it.
Another thing to check is whether you have Windows Firewall enabled, since that might be blocking port 42424.
I've had the same issue when some ASP.NET installation was corrupted. In that case they suggest running aspnet_regiis -i -enable
I've found that some developers will for some reason define the server's private IP outside of IIS in an unexpected location, like a nonstandard config file (i.e. not web.config) or a text file. This can cause internal operation to fail even when the service is started, ports aren't being blocked, reg keys are correct, etc.
Kaseya, in particular, places a file called serveripinternal.txt in the root IIS directory of the VSA server. I've seen the text of your error when somebody running their own Kaseya instance changed the server's internal IP. The server will be reachable, IIS will respond, and the login page will come up - but login will fail with the cited message.
Not the best answer, but it's an option anyway:
Comment the given line in the web.config.
I recently ran into this issue and none of the solutions proposed fixed it. The issue turned out to be an excessive use of datasets stored in the session. There was a flaw in the code that results in the session size to increase 10x.
There is an article on the msdn blog that also talks about this.
http://blogs.msdn.com/b/johan/archive/2006/11/20/sessionstate-performance.aspx
I used a function to write custom trace messages to measure the size of the session data on the live site.