similar to: [Bug 1851] New: ssh_selinux_setfscreatecon segfaults if SELinux support is compiled in but is disabled at run-time

https://bugzilla.mindrot.org/show_bug.cgi?id=1850 Summary: Build fails when SELinux is enabled Product: Portable OpenSSH Version: 5.7p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

the memory which is allocated by matchpathcon should be freed after it is useless Signed-off-by: Roy Li <rongqing.li at windriver.com> --- openbsd-compat/port-linux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/openbsd-compat/port-linux.c +++ b/openbsd-compat/port-linux.c @@ -217,8 +217,10 @@ ssh_selinux_setfscreatecon(const char *p setfscreatecon(NULL);

The memory which is allocated by matchpathcon should be freed after it is used Signed-off-by: Roy Li <rongqing.li at windriver.com> --- openbsd-compat/port-linux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/openbsd-compat/port-linux.c +++ b/openbsd-compat/port-linux.c @@ -217,8 +217,10 @@ ssh_selinux_setfscreatecon(const char *p setfscreatecon(NULL); return;

OpenSSH 5.8 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

---------------------------------------------------- Summary: fix a memory leak for Openssh ---------------------------------------------------- Upstream Project Name: OpenSSH Upstream Project URL: anoncvs at anoncvs.mindrot.org:/cvs Applies to: anoncvs at anoncvs.mindrot.org:/cvs Brief Description: the memory which is allocated by matchpathcon should be freed after it is used Will Submit to:

Hi there is unpaired brackets in port_linux_compat.c in ssh_selinux_setfscreatecon if (path == NULL) setfscreatecon(NULL); return; } -- JFCh <jchadima at redhat.com>

I upgraded my container from CentOS 6.4 to CentOS 6.5. Everything looks good after upgrade until reboot. When rebooted to container I'm getting the following errors.. Any help would be greatly appreciated /bin/mknod: `/dev/lp2': Operation not permitted /bin/chown: cannot access `/dev/lp2': No such file or directory /bin/mknod: `/dev/lp3': Operation not permitted /bin/chown: cannot

On Fri, Nov 14, 2014 at 07:32:46PM +0000, mallu mallu wrote: > I upgraded my container from CentOS 6.4 to CentOS 6.5. Everything looks good after upgrade until reboot. When rebooted to container I'm getting the following errors.. Any help would be greatly appreciated > /bin/mknod: `/dev/lp2': Operation not permitted > /bin/chown: cannot access `/dev/lp2': No such file or

Hi, OpenSSH 5.9 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and changes and bug fixes. Testing of the new sandboxed privilege separation mode (see below) would be particularly appreciated. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The

Hi, I've done the following: - Copy usr content with rsync to another partition: rsync -av --partial --progress /usr/ /mnt Then, unmounted, added to fstab a line for /usr, then deleted /usr/* (not the directory itself). But I've found that is bad labeled: ls -Z /usr unconfined_u:object_r:unlabeled_t:s0 bin unconfined_u:object_r:unlabeled_t:s0 local unconfined_u:object_r:unlabeled_t:s0

Hello everyone, If create a folder called "whatever" under /var, the context is: root:object_r:var_t /var/whatever/ That's expected as it is under /var. If I then change its type: chcont -t httpd_sys_content_t /var/whatever The context looks like: root:object_r:httpd_sys_content_t /var/whatever/ My question is...Shouldn't a relabeling of the filesystem change the type

Hola Amigos: Gracias por todas las respuestas sobre como filtrar datos en un data frame. Ahora tengo un nuevo problema, necesito instalar R 2.15 manualmente, pero no puedo hacerlo desde un repositorio. Alguna solución??????????' Un Saludos, Leonardo ------------ próxima parte ------------ An embedded and charset-unspecified text was scrubbed... Name: no disponible URL:

We don't generate any .lib as those don't work well with incremental linking (and give zero advantages when linking AFAIK), and it would be pretty easy to have a modern format for having a .ghash for multiple files, something simple like size prefixed name and then size prefixed ghash blobs. On Fri, Jan 26, 2018 at 8:44 PM, Zachary Turner <zturner at google.com> wrote: > We

Look for this code in lld/coff/pdb.cpp if (Config->DebugGHashes) { ArrayRef<GloballyHashedType> Hashes; std::vector<GloballyHashedType> OwnedHashes; if (Optional<ArrayRef<uint8_t>> DebugH = getDebugH(File)) Hashes = getHashesFromDebugH(*DebugH); else { OwnedHashes = GloballyHashedType::hashTypes(Types); Hashes = OwnedHashes; } In the else block there, add a log

You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), but all these per-lib PDBs would have to be merged into a single master PDB at the end, so you still can't avoid that final . In a way, that's similar to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to eliminate the cost of merging types and symbol records) and we know what the problems with

it does. I just had an epiphany: why not just write a .ghash file and have lld read those if they exist for an .obj file? Seem much simpler than trying to wire up a 20 year old file format. I will try to do this, is something like this acceptable for LLD? The cool thing is that I can generate .ghash for .lib or any obj lying around (maybe even for pdb in the future). On Fri, Jan 26, 2018 at

I don’t have pgo numbers. When I build using -flto=thin the link time is significantly faster than msvc /ltcg and runtime is slightly faster, but I haven’t tested on a large variety of different workloads, so YMMV. Link time will definitely be faster though On Sun, Jan 28, 2018 at 2:20 PM Leonardo Santagada <santagada at gmail.com> wrote: > This part is only for objects with /Z7 debug

Not a lot. /TIME will show high level timing of the various phases (this is the same option MSVC uses). If you want anything more detailed than that, vTune or ETW+WPA ( https://github.com/google/UIforETW/releases) are probably what you'll need to do. (We'd definitely love patches to improve performance, or even just ideas about how to make things faster. Improving link speed is one of

Part of the reason why lld is so fast is because we map every input file into memory up front and rely on the virtual memory manager in the kernel to make this fast. Generally speaking, this is a lot faster than opening a file, reading it and processing a file, and closing the file. The downside, as you note, is that it uses a lot of memory. But there's a catch. The kernel is smart enough

So I found all 20 bytes and changed then to GHASH_SIZE (a const I defined in typehashing.h) and finished the switch to xxHash64, that saved me around 50 seconds to 56s, then I changed it to uint64_t instead of a 8 byte uint_8 array and that gave me 48s. With release config and a pgo pass I'm now linking in 38s... so faster than link.exe in vs 2017 (which is faster than vs 2015) doing fastlink.