Cannot run execve on files that are blocked to /usr/libexec/amfid - authorization

I wanted to use Kauth in order to block some files from being executed by other processes except mine. However, it seems like even I cannot run the process since I also block the file from amfid (The mobile file integrity daemon, funny it's also existed in macOS).
Here's the following path to the process /usr/libexec/amfid
does my assumption right ? does any mach-o file need to be accessed by amfid for inspection prior to execution ?

Related

Running wrapper file continuously for using JFR to monitor ActiveMQ performance

I have an issue about continuously running Java Flight Recorder to monitor memory usage and other performance statistics of ActiveMQ.
Wrapper configuration file (wrapper.conf) is under this directory with nearside (wrapper, activemq, libwrapper.so) files;
../apache-activemq-5.12.1/bin/linux-x86-64/wrapper.conf
I added the lines below to run JFR;
wrapper.java.additional.13=-XX:+UnlockCommercialFeatures
wrapper.java.additional.14=-XX:+FlightRecorder
wrapper.java.additional.15=-XX:FlightRecorderOptions=defaultrecording=true,disk=true,repository=../jfr/jfrs_%WRAPPER_PID%,settings=profile
wrapper.java.additional.16=-XX:StartFlightRecording=filename=../jfr/jfrs_%WRAPPER_PID%/myrecording.jfr,dumponexit=true,compress=true
When I run wrapper file, expected output 'myrecording.jfr' is generated under specified path in wrapper.conf. But the problem is, I also want it to be happen automatically (without running wrapper file by hand).
What might be the possible solution for that?

Is it safe to delete Selenium.log from my CentOS server?

It seems that I've run out of room on my Master node and I need to clear some space in order to reboot my daily tests. Selenium.log is taking up a lot of space and I'm convinced its not currently being used. Would it be safe to delete?
Edit: I deleted the file and upon starting a new build Selenium created a new log file. I didn't experience any issues during this new build either.
You don't say what creates the file, or where it is, but assuming that you can already see the important details from each build in the Jenkins UI (e.g. in the console log, or in test results etc.), then you shouldn't need to keep any files that are sitting in the workspace or elsewhere.

My compiled *.exe-file can't create files in windows 8.1

I'm using freepascal. So after I run my code compiler creates an exe file that should create few text files. However after it creates an exe file it says "Program c:\fpc\2.6.4\bin\i386-win32\maxmin.exe exited with exitcode = 2". No text files are created. If I later run maxmin.exe manually - it works fine.
UAC - disabled and EnableLUA = 0. But I still pretty sure - it is windows 8.1 rights issue problem.
Some possibilities, in descending order of likeliness:
Note that exitcode 2 usually indicates a file not found error.
Working directory. While manually executing you set the working directory by CDing with the shell, and when indirectly executing the program's assumptions about a working directory are not satisfied.
Sometimes locks linger on Windows for a short while. Usually not noticeable in the manual execution time frames, but when programmatically executing programs in quick succession it might happen.
If you have the feeling that the EXE doesn't run at all, it might be an security software issue. After the binary is generated, the antivirus kicks in and wants to scan, locking the binary for a few seconds.

Permission denied, caused by an NSURL resource leak?

My Mac app copies files the user drags in. The app is sandboxed. I've got a bug now, which I can reliably reproduce in Xcode, but which I can't track down the source of.
When I add a certain number of files, the app suddenly stops being able to access the later ones. All the source files come one level down from the same parent directory, and all of the folders in between have the same permissions, verified with ls -l. The app retains an app-scoped bookmark to Destination Directory, which is accessed before creating .directoryName and beginning the file copy.
I get the error:
Error Domain=NSCocoaErrorDomain Code=513 "“Filename.ext” couldn’t be copied because you don’t have permission to access “.directoryName”." UserInfo=0x6080000eaf80 {NSSourceFilePathErrorKey=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUserStringVariant=(
Copy
), NSDestinationFilePath=/Users/Username/Desktop/Destination Directory/.directoryName/Filename.ext, NSFilePath=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUnderlyingError=0x6080004567a0 "The operation couldn’t be completed. Operation not permitted"}
I have done the following while debugging:
Tried adding Subdir/Filename.ext on its own after quitting and relaunching, which worked
Verified (with lsof and Activity Monitor) that I'm not leaking file handles (which I know has caused similar problems for me in the past)
Verified with symbolic breakpoints that every call to -[NSURL startAccessingSecurityScopedResource] to is balanced with a call to -[NSURL stopAccessingSecurityScopedResource] (and their CF equivalents)
Determined that Filename.ext, and the other files that fail, succeed when added without the others
The same behavior occurs for Debug and Release builds, in and out of the debugger
I tried running as root, but my app won't run that way. When running in the debugger, I get an EXC_BAD_INSTRUCTION exception, and running it with sudo on the command line produces a crash (probably the same one)
The behavior seems to indicate some sort of resource leak, but it's not anything I've yet been able to detect. Any ideas what else might be causing this?
Update
I'm not ready to declare an answer, but I started to get these permission errors in a different part of my code, after a user has dropped files into the app. I noticed that a little ways up the logs, I'd see messages like the following:
Consume sandbox extension for itemIdentifier (1) from pasteboard failed!
Tracking down this error led me to a question someone else asked: Sandboxed Mac app exhausting security scoped URL resources
Unfortunately, the accepted answer says (paraphrasing) "tough noogies". It seems that Cocoa and the sandboxing mechanism themselves are leaking the security-scope tokens (though I can't verify with symbolic breakpoints and know of no other way to check). After a certain (unknown) number of file operations on sandboxed files, you'll start getting this error, and the only solution is to quit and relaunch.
I wish there was at least some way to prompt the user to relaunch when it gets close, but I'm not sure of any way to measure how many of these handles are in use. Or, even better, if I could manually clean up after I finish handling the dropped files, but I'm not sure how that would work, since I need to use the NSFilenamesPboardType pasteboard type to get multiple files' paths. I tried creating NSURLs from these and stopping security scope access, but that had no effect.
Update 2
I submitted a DTS ticket for this, as it's affecting users and there is no clear workaround. I'll update the question (and maybe give an answer?) as I find out more.
Response from Apple's DTS team
Apparently, this is a known issue, with no available workaround. I submitted a Radar: rdar://20652066, if you'd like to dupe it.
This was fixed in an El Capitan (10.11) release (possibly the first, but I'm not sure). When I built my app against the updated SDK, the behavior returned to normal.

Gulp with WinSCP - livereload and less

I am using gulp with livereload, less, and others on a remote server. I have successfully used gulp before many times, and have never experienced this scenario.
I am using WinSCP to save/edit files (I double click the file, and it opens in Sublime Text ... I save it, WinSCP automatically uploads it back to the server ).
However, when doing it this way gulp-less fails almost all the time. I have two core CSS files that are compiled - one is Bootstrap and one is my own - they should both be compiled with their own gulp tasks upon modification - but Bootstrap fails every time, and the other file fails about half of the time.
When I say fails, here's what I mean - with Bootstrap I always get the same error:
variable #grid-columns is undefined in file ....grid.less line no. 48
This happens even if I define #grid-columns as the first-heading in my main Bootstrap "import" file.
The other one fails in that livereload reloads the compiled CSS at some point prior to the Less file being compiled. This should be impossible, but it happens somehow.
However, when from the SSH command prompt, I type touch myfile.less or touch anybootstrapfile.less, everything works perfectly.
Obviously this is very annoying, but its livable. I think there must be some way to fix it though. Any ideas on what in the world could make this happen and what (if anything) I could do to fix it?
Chances are that, when WinSCP uploads the file after you save it in the internal editor, it sets a timestamp of uploaded file to older than it was before.
This might be particularly true, if you are using the FTP protocol, or Windows Vista or older.
For details, refer to WinSCP FAQ:
Why are the changes, I upload to webserver, not visible in the web browser?
Alright. With the help of Martin, who I now realize is the developer of WinScp, I have solved this. I had been working with the gulp.wait plugin and inserting a pause before the final reload - and it wasn't working.
Because... that wasn't where the problem was. The problem was happening at the time of upload; in that the file was getting 'touched' to soon (or there was something with the timestamp that ended up causing the functional equivelant).
So I moved the wait process to just before the less process was called like so:
gulp.src(src)
.pipe(plumber({
errorHandler:onError
})
.pipe(wait(500))
.pipe(less())
//etc
I'm gonna experiment, 500ms is probably longer than needed..but not too long to be painful. This solved the problem instantly.
Thanks Martin!