Here is the code.
android::sp<android::GraphicBuffer> graphicBuffer = new android::GraphicBuffer(width, height, 0x1000, flags);
Can I get the file descriptor from the graphicBuffer ?
Related
I am interested in /proc/sys and trying to understand the access control mechanism of files in this directory.
I am not sure if accessing /proc/sys is the same as accessing on-disk file systems, like ext4. So I just started with the open system call and tried to trace critical kernel functions called among the process.
And found that it first called do_sys_open(), which called do_filp_open() internally. In do_filp_open(), some path name resolution is done at first and then it called may_open() to do some permission checks, and finally vfs_open() is called to do the specific open function according to the file system.
From reading the source code, I suppose the permission check work is indeed done by generic_permission() which located in /fs/namei.c. The whole function looks like this:
int generic_permission(struct inode *inode, int mask)
{
int ret;
/*
* Do the basic permission checks.
*/
ret = acl_permission_check(inode, mask);
if (ret != -EACCES)
return ret;
if (S_ISDIR(inode->i_mode)) {
/* DACs are overridable for directories */
if (capable_wrt_inode_uidgid(inode, CAP_DAC_OVERRIDE))
return 0;
if (!(mask & MAY_WRITE))
if (capable_wrt_inode_uidgid(inode,
CAP_DAC_READ_SEARCH))
return 0;
return -EACCES;
}
/*
* Read/write DACs are always overridable.
* Executable DACs are overridable when there is
* at least one exec bit set.
*/
if (!(mask & MAY_EXEC) || (inode->i_mode & S_IXUGO))
if (capable_wrt_inode_uidgid(inode, CAP_DAC_OVERRIDE))
return 0;
/*
* Searching includes executable on directories, else just read.
*/
mask &= MAY_READ | MAY_WRITE | MAY_EXEC;
if (mask == MAY_READ)
if (capable_wrt_inode_uidgid(inode, CAP_DAC_READ_SEARCH))
return 0;
return -EACCES;
}
So, it seems like UGO check comes at first, if UGO failed kernel will check if you have special Capability. But this process is not consistent with the experiment result I saw when I tried access files under /proc/sys. Take /proc/sys/kernel/usermodehelper/bset as an example:
$ ll /proc/sys/kernel/usermodehelper/bset
-rw------- 1 root root 0 Nov 6 12:15 /proc/sys/kernel/usermodehelper/bset
This file is owned by root and can’t be read from others. From the logic in generic_permission(), non-root could read this file if he has CAP_DAC_OVERRIDE. So I give /bin/cat CAP_DAC_OVERRIDE, but got an “Permission denied” and still cannot read the file.However, I could read /etc/shadow after grand CAP_DAC_OVERRIDE to cat, which is also a root file and can't be read by a normal user.
Why did this happen？What is the permission check process like when accessing files under /proc/sys? Doesn’t it go through generic_permission()? Is there some other check in kernel when accessing /proc/sys?
I'm simply trying to overwrite the contents of a pre-generated (written with allocUnsafe(size)) 1GB file via a 4 byte buffer at an iterating offset, and before I open the file descriptor, fs.stat and the Windows file system show the correct size. As soon as I open the file descriptor, it appears both in fs.stat and in the file system the file is empty:
let stats = fs.statSync(dataPath)
let fileSizeInBytes = stats["size"]
let fileSizeInMegabytes = fileSizeInBytes / 1000000
console.log("fileSizeInMegabytes", fileSizeInMegabytes) // => fileSizeInMegabytes 1000
fd = fs.openSync(dataPath, 'w')
stats = fs.statSync(dataPath)
fileSizeInBytes = stats["size"]
fileSizeInMegabytes = fileSizeInBytes / 1000000
console.log("fileSizeInMegabytes", fileSizeInMegabytes) // => fileSizeInMegabytes 0
Why is opening the file descriptor emptying my file? Surely I'm missing something obvious, but I can't see it.
Opening the file using the w flag truncates the file, i.e. removes any contents.
You should use r+ to read and write to the file without wiping it clean.
For more info, check out the Node docs and the answers on this question.
So I have 6 seperate images and I would like to build a textureCube out of them. What's the best way to go about it? Right now this is what I have, but I'm getting a memory access violation when the TextureCube tries to create itself.
SharpDX.DataBox[] textureData = new SharpDX.DataBox[6];
for(int i = 0; i < 6; i++)
{
Texture2D tex = Texture2D.Load(device, resources[i].Filepath);
SharpDX.Direct3D11.Texture2D staged = (SharpDX.Direct3D11.Texture2D)tex.ToStaging();
textureData[i] = new SharpDX.DataBox(staged.NativePointer, staged.Description.Width, 0);
}
SharpDX.Toolkit.Graphics.TextureCube cube = SharpDX.Toolkit.Graphics.TextureCube.New(
device,
2048,
PixelFormat.R8G8B8A8.UNorm,
textureData);
The texture load is working fine. I can load the texture and then create a textureCube from a single image no problem. That's not much use though. When I try to create a cube using the raw data from my 6 separate images I'm getting the memory exception.
Result Message:
Test method ResourceLoadingTests.LoadCubemapAndSave threw exception:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Result StackTrace:
at SharpDX.Direct3D11.Device.CreateTexture2D(Texture2DDescription& descRef, DataBox[] initialDataRef, Texture2D texture2DOut)
at SharpDX.Direct3D11.Texture2D..ctor(Device device, Texture2DDescription description, DataBox[] data)
at SharpDX.Toolkit.Graphics.Texture2DBase..ctor(GraphicsDevice device, Texture2DDescription description2D, DataBox[] dataBoxes)
at SharpDX.Toolkit.Graphics.TextureCube..ctor(GraphicsDevice device, Texture2DDescription description2D, DataBox[] dataBoxes)
at SharpDX.Toolkit.Graphics.TextureCube.New(GraphicsDevice device, Int32 size, PixelFormat format, DataBox[] textureData, TextureFlags flags, ResourceUsage usage)
Hi Can you please let me know how to find the file size, below is the code I am using to create the file & to write the data to the file.
String^ path = "C:\\Users\\Mani\\Desktop\\"+textBox2->Text+".txt";
StreamWriter^ sw ;
if ( !File::Exists( path ) )
{
File_flag = 1;
// Create the file.
sw = File::CreateText( path );
sw->WriteLine("***Log File***");
sw->WriteLine(DateTime::Now);
sw->WriteLine("**************");
}
I tried to decode the audio using ffmpeg with the following code:
NSMutableData *finalData = [NSMutableData data];
......
while(av_read_frame(pFormatCtx, &packet) >= 0){
if(packet.stream_index == videoStream)
{
int consumed = avcodec_decode_audio4(pCodecCtx, pFrame, &got_frame_ptr, &packet);
if(got_frame_ptr)
{
[finalData appendBytes:(pFrame->data)[0] length:(pFrame->linesize)[0]];
}
}
av_free_packet(&packet);
}
......
[finalData writeToFile:path atomically:YES];
Bu the saved file can't be played, even I changed the file extension to wav. When I look into it in HexEdit (a Hex editor), I found there are many zero bytes. For example the content of the file before offset 0x970 are all zero. Is there any error in my code? Any help will be appreciated.
Actually the decode result is good. The zero bytes in the file is normal, because the decode result is PCM data. I tried to import the data into Adobe Audition, it can be played. FYI.