From owner-freebsd-hackers@freebsd.org Mon Jan 27 16:27:23 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 542FD1FB1E9 for ; Mon, 27 Jan 2020 16:27:23 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 485wBd0rfPz4YB5 for ; Mon, 27 Jan 2020 16:27:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 780C616054; Mon, 27 Jan 2020 17:27:13 +0100 (CET) Date: Mon, 27 Jan 2020 17:27:13 +0100 From: Steffen Nurpmeso To: Yuri Pankov Cc: freebsd-hackers@freebsd.org, Ingo Schwarze Subject: Re: Fwd: Re: Long (-- style) options (.Fl) with mdoc(7) Message-ID: <20200127162713.9UoUn%steffen@sdaoden.eu> In-Reply-To: References: <20200124194444.GK35815@athene.usta.de> Mail-Followup-To: Yuri Pankov , freebsd-hackers@freebsd.org, Ingo Schwarze User-Agent: s-nail v14.9.16-88-gce582480-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 485wBd0rfPz4YB5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [0.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.862,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.12)[0.124,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.132.0/24, country:DE]; IP_SCORE(0.29)[asn: 15987(1.48), country: DE(-0.02)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 16:27:23 -0000 Hello. Sorry for the late reply. Yuri Pankov wrote in : |Forwarding on behalf of Ingo as he isn't subscribed, and the message=20 |provides useful content. | |-------- Forwarded Message -------- |Subject: Re: Long (-- style) options (.Fl) with mdoc(7) |Date: Fri, 24 Jan 2020 20:44:44 +0100 |From: Ingo Schwarze |To: Yuri Pankov |CC: freebsd-hackers@freebsd.org | |Hi Yuri, | |Yuri Pankov wrote on Fri, Jan 24, 2020 at 09:56:03PM +0300: |> Steffen Nurpmeso wrote: |>> Yuri Pankov wrote in : |>>> Steffen Nurpmeso wrote: | |>>>> The very moment i have seen a showmount(8) change fly by, and |>>>> wanted to make you aware of the persuading approach that NetBSD's |>>>> wizd(8) uses, namely ".Fl Fl long-option". | |The reason why that is a bad idea is that it is semantically wrong. |The meaning of ".Fl Fl long-option" is: | | The option "-" (as in the traditional "su -") followed by the=20 |other, additional option "-long-option" I really think you are splitting hairs here. Long options are a very common thing, and using "Fl Fl opt" as opposed to "Fl -opt" seems to fit the task more nicely for me; having a special command for this would be even better, but that we do not have. The option is "opt", not "-opt". |>>>> Different to ".Fl -long-option" this produces visually appealing |>>>> results on all output devices. | |That is doubtful: | | $ echo .Fl Fl long-option | mandoc -mdoc -Thtml | [...] | --long-option | [...] I think it would be worth adding special code to make it happen, then. |You get two separate elements which can screw CSS markup. Hm. |>>> mandoc style guide advises differently: |>>> https://mandoc.bsd.lv/mdoc/style/options.html |>>> It's not authoritative, of course, but I'm not aware of any other mdoc |>>> style guide. May be you could take it up to style guide/mandoc \ |>>> authors? | |>> I can Cc: him. That is _he_, who is totally opposed against long- |>> options, isn't he? | |Yes. I consider long options a scourge - hard to document, ... |with that opinion: POSIX also discourages them. ... |>> Whatever this guide says, if you do Postscript/PDF output (with |>> groff) then Fl becomes a nice dash, whereas the other thing is |>> a hyphen-minus. | |That just isn't true: | | $ cat tmp.mdoc | .Fl \-long\-option ... But this is "Fl \-opt", then. I did not use that back in the day, before i saw wizd's comment "i would use Fl Fl", and it made a difference for me by then. I mean, the nice clean semantic syntax of mdoc(7) as opposed to man(7) where you work with \- anyway is appealing: .Op : Ns Fl C Ar """field:\0body""" Ns \&: .Op : Ns Fl c Ar cc-addr Ns \&: .Op Fl M Ar type | Fl m Ar file | Fl q Ar file | Fl t .Op Fl r Ar from-addr .Oo : Ns Fl S\0 Ns Ar var Ns Oo Ns =3D Ns Ar value Ns Oc Ns : Ns Oc =C2=BBKlar wie Klo=C3=9Fbr=C3=BChe=C2=AB. ... | $ less /co/groff/tmac/doc.tmac-u | [...] | .de Fl | [...] | . nop \|\-\f[]\s[0]\c | [...] | |So, *typographically*, | | .Fl Fl long\-option | |and | | .Fl \-long\-option | |produce exactly the same when disregarding \| spaces. The difference |is purely *semantic*, and in that respect, .Fl Fl is clearly wrong. Hm, maybe i should use \- for inter-argument-word separators, too. "Ns Fl" would surely be false for those.. |> Note that I don't disagree on using Fl Fl, and quite some of our man=20 |> pages already do it, I just want it documented at least somewhere so=20 |> it's possible to link to it if there's a question how something should= =20 |> be done. | |The "Fl Fl" idiom is not so bad that it is urgent to fix it, i think |there are some "Fl Fl" in OpenBSD too, but it is better avoided. I only did not use it because i did not know it works. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Mon Jan 27 20:11:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62EF522C763; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48619K2dZbz46PL; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1472) id 4E994699D; Mon, 27 Jan 2020 20:11:33 +0000 (UTC) To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2019 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Message-Id: <20200127201133.4E994699D@freefall.freebsd.org> Date: Mon, 27 Jan 2020 20:11:33 +0000 (UTC) From: Lorenzo Salvadore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 20:11:33 -0000 FreeBSD Project Quarterly Status Report - Fourth Quarter 2019 Here is the last quarterly status report for 2019. As you might remember from last report, we changed our timeline: now we collect reports the last month of each quarter and we edit and publish the full document the next month. Thus, we cover here the period October 2019 - December 2019. If you thought that the FreeBSD community was less active in the Christmas' quarter you will be glad to be proven wrong: a quick glance at the summary will be sufficient to see that much work has been done in the last months. Have a nice read! -- Lorenzo Salvadore __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Foundation * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration Projects * IPSec Extended Sequence Number (ESN) support * NFS Version 4.2 implementation * DTS Update * RockChip Support * Creating virtual FreeBSD appliances from RE VMDK images Kernel * SoC audio framework and RK3399 audio drivers * FreeBSD on Microsoft HyperV and Azure * FreeBSD on EC2 ARM64 * ENA FreeBSD Driver Update Architectures * PowerPC on Clang * NXP ARM64 SoC support Userland Programs * Linux compatibility layer update Ports * Ports Collection * KDE on FreeBSD * Java on FreeBSD * Electron and VSCode * Bastille * Universal Packaging Tool (upt) * Wine on FreeBSD Third-Party Projects * sysctlbyname-improved * pot and the nomad pot driver * 7 Days Challenge * NomadBSD __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. * Julie Saravanos, the sister of Bruce D. Evans (bde), mailed core with the sad news that Bruce passed away on 2019-12-18 at the age of 68 years. Bruce was a deeply respected member of the community, served on the Core team, and made over 5,000 commits. Bruce's impact on our culture was so profound that new terminology was spawned. This is an excerpt of a message from Poul-Henning Kamp to Julie. I don't know precisely when I first communicated with Bruce, it was in the late 1980'ies via "UseNET", but I can say with certainty that few people have inspired me more, or improved my programming more, than Bruce he did over the next half of my life. All large projects invent its own vocabulary and in FreeBSD two of the neologisms are "Brucification", and "Brucified". A "brucification" meant receiving a short, courteous note pointing out a sometimes subtle deficiency, or an overlooked detail in a source code change. Not necessarily a serious problem, possibly not even a problem to anybody at all, but nonetheless something which was wrong and ought to be fixed. It was not uncommon for the critique to be considerably longer than the change in question. If one ignored brucifications one ran the risk of being "brucified", which meant receiving a long and painstakingly detailed list of every single one of the errors, mistakes, typos, shortcomings, bad decisions, questionable choices, style transgressions and general sloppiness of thinking, often expressed with deadpan humor sharpened to a near-fatal point. The most frustrating thing was that Bruce would be perfectly justified and correct. I can only recall one or two cases where I were able to respond "Sorry Bruce, but you're wrong there..." - and I confess that on those rare days I felt like I should cut a notch in my keyboard. The last email we received from Bruce is a good example of the depth of knowledge and insight he provided for the project: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=1163414+0+archive/2019/svn-src-all/20191027.svn-src-all * The 12.1 release was dedicated to another FreeBSD developer who passed away in the fourth quarter of 2019, Kurt Lidl. The FreeBSD Foundation has a memorial page to Kurt. https://www.freebsdfoundation.org/blog/in-memory-of-kurt-lidl/ We send our condolences to both the families of Bruce and Kurt. * Core has documented The Project's policy on support tiers. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html * Core approved a source commit bit for James Clarke. Brooks Davis (brooks) will mentor James and John Baldwin (jhb) will co-mentor. * The Project's first Season of Docs ended with a negative result. The work was not completed and contact could not be established with the writer. No payment was made and the financing was set aside for future work. * Google Summer of Code completed. Information about the seven accepted projects can be found on the wiki page. https://wiki.freebsd.org/SummerOfCode2019Projects * Adam Weinberger (admaw) was added to conduct@. Adam has demonstrated competence, understanding, and fairness in personal matters. * Li-Wen Hsu (lwhsu) contacted Core after receiving a report from concerned local community members about past updates to The Project's internationalization policy. Lengthy discussions took place to determine how to reaffirm that The Project maintains a neutral position in political disputes. Updates were made to the document and it was decided that any future changes would require explicit Core approval. https://www.freebsd.org/internal/i18n.html * After nomination by Edward Napierała (trasz), core voted to grant Daniel Ebdrup (debdrup) and Lorenzo Salvadore (salvadore) membership in The Project. Both Daniel and Lorenzo have been working on the quarterly reports for the past few quarters. * The Core-initiated Git Transition Working Group continued to meet over the last quarter of 2019. Their report is still forthcoming. __________________________________________________________________ FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. In Q4, Ed Maste and Deb Goodkin met with a few commercial users in the US. It's not only beneficial for the above, but it also helps us understand some of the applications where FreeBSD is used. We were also able to meet with a good number of commercial users at the Bay Area Vendor/Developer Summit and Open Source Summit Europe. These venues provide an excellent opportunity to meet with commercial and individual users and contributors to FreeBSD. Fundraising Efforts In 2019, we focused on supporting a few key areas where the Project needed the most help. The first area was software development. Whether it was contracting FreeBSD developers to work on projects like wifi support, to providing internal staff to quickly implement hardware workarounds, we've stepped in to help keep FreeBSD innovative, secure, and reliable. Software development includes supporting the tools and infrastructure that make the development process go smoothly, and we're on it with team members heading up the Continuous Integration efforts, and actively involved in the clusteradmin and security teams. Our advocacy efforts focused on recruiting new users and contributors to the Project. We attended and participated in 38 conferences and events in 21 countries. From giving FreeBSD presentations and workshops to staffing tables, we were able to have 1:1 conversations with thousands of attendees. Our travels also provided opportunities to talk directly with FreeBSD commercial and individual users, contributors, and future FreeBSD users/contributors. We've seen an increase in use and interest in FreeBSD from all of these organizations and individuals. These meetings give us a chance to learn more about what organizations need and what they and other individuals are working on. The information helps inform the work we should fund. In 2019, your donations helped us continue our efforts of supporting critical areas of FreeBSD such as: * Operating System Improvements: Providing staff to immediately respond to urgent problems and implement new features and functionality allowing for the innovation and stability you've come to rely on. * Improving and increasing test coverage, continuous integration, and automated testing with a full-time software engineer to ensure you receive the highest quality, secure, and reliable operating system. * Security: Providing engineering resources to bolster the capacity and responsiveness of the Security team providing you with peace of mind when security issues arise. * Growing the number of FreeBSD contributors and users from our global FreeBSD outreach and advocacy efforts, including expanding into regions such as China, India, Africa, and Singapore. * Offering FreeBSD workshops and presentations at more conferences, meetups, and universities around the world. * Providing opportunities such as developer and vendor summits and company visits to help facilitate collaboration between commercial users and FreeBSD developers, as well as helping to get changes pushed into the FreeBSD source tree, and creating a bigger and healthier ecosystem. We've accomplished a lot this year, but we are still only a small 501(c)3 organization focused on supporting FreeBSD and not a trade organization like many other open source Foundations. Please consider making a donation at https://www.FreeBSDfoundation.org/donate/ to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation supports software development projects to improve FreeBSD through our full time technical staff, contractors, and project grant recipients. They maintain and improve critical kernel subsystems, add new features and functionality, and fix bugs. Between October and December there were 236 commits to the FreeBSD source repository tagged with FreeBSD Foundation sponsorship. This is about 10% of all commits during this period. Some of these projects have their own entries in the quarterly report, and are not repeated here, while others are briefly described below. As usual, Foundation staff member Konstantin Belousov committed a large number of UFS, NFS, tmpfs, VM system, and low-level Intel x86 bug fixes and improvements. Kostik also committed improvements to the run-time linker (rtld), and participated in very many code reviews, helping to get changes from other developers integrated into the tree. Following on from his work to improve debugging tools in the Linuxulator environment, Edward Napierała integrated the Linux Test Project (LTP) with FreeBSD's CI system, and committed a number of small bug fixes to the Linuxulator itself. Mark Johnston continued working on infrastructure for the Syzkaller system call fuzzing tool, and committed fixes for many issues identified by it. Mark committed improvements to RISC-V infrastructure, the network stack, performance and locking, and x86 pmap. Mark also added support for newer Intel WiFi chipsets to the iwm driver, enabling WiFi support for the Lenovo X1 Carbon 7th generation, and other contemporary laptops. Ed Maste committed a number of improvements and cleanups in build infrastructure, vt console fixes including issues with keyboard maps, some blacklistd updates, documentation updates, and other small changes. Ed also committed some work to prepare for the removal of GCC 4.2.1 from the FreeBSD source tree, currently planned for Q1 2020. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving our automated testing, continuous integration, and overall quality assurance efforts. During the fourth quarter of 2019, Foundation staff continued to improve the project's CI infrastructure, worked with contributors to fix the failing build and test cases. We worked with other teams in the project for their testing needs and also worked with many external projects and companies to improve their support of FreeBSD. We added several new CI jobs and brought the FreeBSD Hardware Testing Lab online. We published 2019 in Review: CI and Testing Advancements on the Foundation's blog. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and helping other FreeBSD contributors volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Check out some of the advocacy and education work we did last quarter: * Organized the 2019 Bay Area FreeBSD Vendor and Developers Summit in Santa Clara, CA * Presented at COSCON '19 in Shanghai, China * Represented FreeBSD at All Things Open 2019, in Raleigh, North Carolina * Industry Partner Sponsor for LISA '19 in Portland, OR * Silver Sponsor of OpenZFS in San Francisco, CA * Gave a technical presentation at School of Mines in Golden, CO * Presenting and representing FreeBSD at Seagl, in Seattle, WA * Presented at Open Source Summit Europe in Lyon France * Committed to sponsoring LinuxConfAu 2020, in Gold Coast, Australia in addition to holding a FreeBSD Mini-Conf * Accepted to present at the BSD Dev Room at FOSDEM '20, in Brussels, Belgium * Accepted to have a stand at FOSDEM '20, in Brussels, Belgium * Committed to sponsoring FOSSASIA 2020, in Singapore * Committed to hold FreeBSD Day at SCALE 18x, in Pasadena, CA We continued producing FreeBSD advocacy material to help people promote FreeBSD. Learn more about our efforts in 2019 to advocate for FreeBSD: https://www.freebsdfoundation.org/blog/2019-in-review-advocacy/ Our Faces of FreeBSD series is back. Check out the latest post: Mahdi Mokhtari. https://www.freebsdfoundation.org/blog/faces-of-freebsd-2019-mahdi-mokhtari/ Read more about our conference adventures in the conference recaps and trip reports in our monthly newsletters: https://www.freebsdfoundation.org/news-and-events/newsletter/ We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. We have continued our work with a new website developer to help us improve our website. Work has begun to make it easier for community members to find information more easily and to make the site more efficient. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 12.1-RELEASE schedule URL: https://www.freebsd.org/releases/12.1R/schedule.html FreeBSD 12.1-RELEASE announcement URL: https://www.freebsd.org/releases/12.1R/announce.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued work on the 12.1-RELEASE, which started September 6th. This release cycle was the first "freeze-less" release from the Subversion repository, and the test bed for eliminating the requirement of a hard code freeze on development branches. The 12.1-RELEASE cycle concluded with the final build beginning November 4th, preceded by three BETA builds and two RC builds. The RC3 build had been included in the original schedule, but had been decided to not be required. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade ref11-{amd64,i386}.freebsd.org to 11.3-STABLE r353313 * Ongoing systems administration work: * Creating accounts for new committers. * Backups of critical infrastructure. * Keeping up with security updates in 3rd party software. Work in progress: * Review the service jails and service administrators operation. * South Africa Mirror (JINX) in progress. * NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. * Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. * Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Setup new host for CI staging environment. * Plan how to add new semi-official pkg mirrors __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report URL: https://hackmd.io/@FreeBSD-CI freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu The FreeBSD CI team maintains continuous integration system and related tasks for the FreeBSD project. The CI system regularly checks the committed changes can be successfully built, then performs various tests and analysis of the results. The results from build jobs are archived in an artifact server, for the further testing and debugging needs. The CI team members examine the failing builds and unstable tests, and work with the experts in that area to fix the code or adjust test infrastructure. The details are of these efforts are available in the weekly CI reports. During the fourth quarter of 2019, we worked with the contributors and developers in the project for their testing needs and also worked with many external projects and companies to improve their support of FreeBSD. The FreeBSD Hardware Testing Lab is online in this quarter. It's still in work in progress stage and we are merging the different versions and will integrate more tightly to the main CI server. We are also working on make this work more easierly to be reproduced. Work in progress: * Collecting and sorting CI tasks and ideas at https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg * Setup the CI stage environment and put the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building test against -CURRENT * Testing and merging pull requests at https://github.com/freebsd/freebsd-ci/pulls * Planning for running ztest and network stack tests * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Adding LTP test jobs. * Adding non-x86 test jobs. * Adding external toolchin related jobs. Please see freebsd-testing@ related tickets for more WIP information. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. IPSec Extended Sequence Number (ESN) support Contact: Patryk Duda Contact: Marcin Wojtas Extended Sequence Number (ESN) is IPSec extension defined in RFC4303 Section 2.2.1. It makes possible to implement high-speed IPSec implementations where standard, 32-bit sequence number is not sufficent. Key feature of the ESN is that only low order 32 bits of sequence number are transmitted over the wire. High-order 32 bits are maintained by sender and receiver. Additionally high-order bits are included in the computation of Integrity Check Value (ICV) field. Extended Sequence Number support contains following: * Modification of existing anti-replay algorithm to fulfil ESN requirements * Trigger soft lifetime expiration at 80% of UINT32_MAX when ESN is disabled * Implement support for including ESN into ICV in cryptosoft engine in both encrypt and authenticate mode (eg. AES-CBC and SHA256 HMAC) and combined mode (eg. AES-GCM) * Implement support for including ESN into ICV in AES-NI engine in both encrypt and authenticate mode and combined mode Remaining work: * Upstream patches of the anti-replay algorithm * Adjust implementation of crypto part after the reworked Open Crypto Framework gets stable This project was sponsored by Stormshield. __________________________________________________________________ NFS Version 4.2 implementation Contact: Rick Macklem RFC-7862 describes a new minor revision to the NFS Version 4 protocol. This project implements this new minor revision. The NFS Version 4 Minorversion 2 protocol adds several optional features to NFS, such as support for SEEK_DATA/SEEK_HOLE, file copying done on the server that avoids data transfer over the wire and support for posix_fallocate(), posix_fadvise(). Hopefully these features can improve performance for certain applications. This project has basically been completed. The code changes have now all been committed to head/current and should be released in FreeBSD 13. Testing by others would be appreciated. To do testing, an up to date head/current system is required. Client mounts need the "minorversion=2" mount option to enable this protocol. The NFS server will have NFSv4.2 enabled by default. __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.4 for HEAD and 5.2 for the 12-STABLE branch. The DTS for the RISC-V architecture are now imported as well. __________________________________________________________________ RockChip Support Contact: Contact: Emmanuel Vadot Contact: Michal Meloun RockChip RK3399 now has USB3 support, some configuration such as device mode are still not supported however host mode should work on any board. Support for SPI has been committed which enables ability to interact with SPI flash if present. All regulators for the RK808 PMIC (Power Management IC) have been added. All clocks are now supported which completes clock and reset implementation, previously only clocks from devices with drivers were supported. The TS-ADC (Temperature Sensor ADC) is now supported, this adds the ability to read temperature of the CPU and GPU via sysctl hw.temperature . Initial PCIe support has been committed and verified working on several different boards. Known working devices are NVMe devices and PCIe cards that doesn't utilize PCIe switching or bridge functionality. Card Detection for SDCard on RK3328 and RK3399 is now supported. There is still some problems if the board is using a GPIO for CD instead of the internal detection mechanism. __________________________________________________________________ Creating virtual FreeBSD appliances from RE VMDK images Links freebsd-mkova URL: https://github.com/gonzoua/freebsd-mkova Contact: Oleksandr Tymoshenko OVA is a file format for packaging and distributing virtual appliances: pre-configured virtual machine images. Virtual appliance file contains full VM information like the number of CPUs, amount of memory, list of virtual devices, it also includes disk images. Applications like VirtualBox or VMWare can import OVA files; this process can be easily automated. freebsd-mkova is a CLI tool to create OVA files using VMDK images provided by FreeBSD RE. For now, only a limited set of attributes can be specified: VM name, number of CPU, amount of memory, and disk size. The tool also does only cursory sanity checks on the VMDK file format, assuming it's a monolithic sparse file and that it has to be converted to the stream-optimized format. The script can be extended to make hardware configuration more flexible and VMDK parser more robust. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and RK3399 audio drivers Links rk3399_audio URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko Most modern SoCs and devboards have audio support in one form or another, but it's one of the areas that are overlooked by FreeBSD driver developers. The most common architecture for the audio pipeline on a single-board computer consists of two DAIs (digital audio interfaces): CPU and codec, connected by a serial bus. CPU DAI is a SoC IP block that operates with samples: obtains them from the driver for playback or provides them to the driver for recording through FIFOs or DMA requests. Audio samples leave (or arrive at) the SoC through a serial bus, usually I2S, that is connected to Codec DAI. Codec DAI is an external (to the SoC) chip that packs one or more DAC/ADC blocks along with mixers, amplifiers, and probably more specialized devices like filters and/or sound effects. The analog part of the codec is connected to microphones/headphones/speakers. On SBCs, the codec usually communicates with SoC through two interfaces: data path, over which audio samples travel, and a control interface that is used to read/write chip registers and configure its behavior. The most common choices for these are I2S and I2C buses, respectively. For FDT-enabled devices, an audio pipeline is described as a virtual DTB node that has links to the CPU and codec device(s), and which specifies the data format, and clock details that both the CPU and the codec chips would use. It also may have more than one CPU/codec pair. Using Firefly-RK3399 as a test device, I was able to implement I2S driver for RK3399 SoC (PIO mode, playback only), the driver for Realtek's RT5640 chip (headphones playback only + mixer controls) and a base outline of SoC audio framework. Some bits of rk_i2s and the framework were ported from the NetBSD code developed by Jared McNeill. On my WIP branch, I can play mp3 audio and control playback volume. The primary missing functionalities at the moment are recording support, multi-link audio cards, DMA support. The most critical among these is DMA support. In the current implementation, all buffer management is placed at the ausoc layer, which is not going to work for DMA, because only the CPU DAI driver would know about the memory constraints and access mechanisms. The current state of RK3399 support does not allow to implement DMA transfers for rk_i2s easily, but I plan to look into this right after adding recording support, which should not be a lot of work. __________________________________________________________________ FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu Wei is working on HyperV Socket support for FreeBSD. HyperV Socket provides a way for host and guest to communicate using common socket interfaces without networking support. Some features in Azure require HyperV Socket support in guest. It is planned to commit the code by the end of February. This project is sponsored by Microsoft. Details of HyperV Socket is available at https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service Li-Wen and Wei are working on improving FreeBSD release on Azure. During this quarter, Wei has published the 11.3-RELEASE on Azure. Li-Wen is working on the FreeBSD release codes related to Azure for the -CURRENT and 12-STABLE branches. This project is sponsored by Microsoft and FreeBSD Foundation. __________________________________________________________________ FreeBSD on EC2 ARM64 Links FreeBSD/ARM 12 in AWS Marketplace URL: https://aws.amazon.com/marketplace/pp/B081NF7BY7 FreeBSD/EC2 Patreon URL: https://www.patreon.com/cperciva M6G vs M5 buildworld cost/time performance URL: https://twitter.com/cperciva/status/1206688489518985216 Contact: Colin Percival In November 2018, Amazon Web Services announced the first Elastic Compute Cloud (EC2) instances built around the ARM64 platform. While FreeBSD supported the ARM64 platform, running on this specific virtual machines took some additional work, but by April 2019 the weekly snapshot builds performed by the Release Engineering Team included ARM64 AMIs for FreeBSD HEAD. In November 2019 FreeBSD 12.1 was released, including the first "RELEASE" FreeBSD EC2/ARM64 AMIs. A few weeks later, FreeBSD/ARM64 was added as a new "product" to the AWS Marketplace. At the re:Invent 2019 conference in December 2019, Amazon announced a second family of ARM64 instances, known variously as "Graviton 2" and "M6G". These are far more powerful than the first-generation ARM64 EC2 instances, and have a roughly 40% price/performance advantage over the "M5" family of x86 EC2 instances; and existing FreeBSD 12.1 and HEAD AMIs run "out of the box" on these instances. Work is currently underway to improve kernel locking scalability on these instances; with high levels of parallelism (e.g. buildworld -j64) the G6M instances have approximately 1.5x higher sys:user ratios than equally-sized M5 instances, suggesting that there is room for improvement here. Two issues have been recently identified, both likely relating to ACPI: * EC2 "StopInstance" API calls, which translate to ACPI "power button" notifications, do not trigger FreeBSD to shut down; this results in a timeout from EC2 and a "hard poweroff". * Hotplugging/unplugging EBS volumes, which normally operates via ACPI device notifications, does not work. Help from developers familiar with ARM64 and ACPI would be much appreciated. This project was sponsored by FreeBSD/EC2 Patreon. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README Contact: Michal Krawczyk Contact: Maciej Bielski Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Upstream of the driver v2.1.0 version, introducing: * Netmap support * Driver structure rework (split datapath code from initialization) * Fix for keep-alive timeout due to prolonged reset * Enable LLQ mode on arm64 instances by enabling memory mapped as WC Work in progress:: * ENA v2.2.0 release, introducing new bug fixes, features and other improvements This project was sponsored by Amazon.com Inc. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. PowerPC on Clang Contact: Justin Hibbits Contact: Brandon Bergren Contact: Alfredo Dal'Ava Júnior Shortly before the end of the year all 3 PowerPC targets (powerpc, powerpc64, powerpcspe) switched to Clang as the base compiler. This was an effort spanning nearly the full year, with several people involved. 32-bit PowerPC platforms (powerpc, powerpcspe) still require GNU ld, but powerpc64 uses LLD as the base linker. The other two platforms will migrate as soon as LLD is ready, which should be in the next several months. With the switch to Clang and LLD, powerpc64 also switched to ELFv2, a modern ABI initially targeted for Linux powerpc64le (little endian), but the ABI itself is endian agnostic; however, ELFv2 is binary incompatible with ELFv1. FreeBSD is still big endian on all powerpc targets. __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * QSPI * Network performance improvements Todo: * Upstreaming of developed features. This work is expected to be submitted/merged to HEAD in the Q1 of 2020. This project was sponsored by Alstom Group. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Linux compatibility layer update Contact: Edward Tomasz Napierala Linux binaries of Linux Test Projects tests are now part of the FreeBSD Continuous Integration infrastructure. This makes it easy to track progress in improving the Linux compatibility layer, and to detect regressions. There was a fair number of all kinds of improvements to the layer, ranging from updated linux(4) man page, to a new linux rc script, which now takes care of eg mounting Linux-specific filesystems or setting ELF fallback brand, to new syscalls, to tiny improvements such as making ^T work for Linux binaries. From the user point of view, when running 13-CURRENT, Linux jails are now in a mostly working state: you can SSH into a jail with CentOS 8 binaries, run screen(1), Emacs, Postgres, OpenJDK 11, use yum upgrade... Of course there's still a bunch of things that need work: * There is a patch from chuck@ that makes core dumps work for Linux binaries; this will make debugging much easier * There are pending reviews for patches that add extended attributes support, fexecve(2) syscall, sendfile; they require wrapping up and committing * There are over 400 failing LTP tests. Some of them are false positives, some are easy to fix bugs, some require adding new system calls. Any help is welcome. This project was sponsored by FreeBSD Foundation. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team URL: https://www.freebsd.org/portmgr/index.html Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. This entry shows what happened in the last quarter. 2019Q4 closed with a total of 38,200 ports and 2180 open PRs of which a small 470 PRs are unassigned. Last quarter saw 7907 commits from 157 committers to the HEAD branch and 358 commits from 61 committers to the 2019Q4 branch. This seems to suggest a small increase in activity compared to the quarter before. During the last quarter, we welcomed Oleksii "Alex" Samorukov (samm@) and Scott Long (scottl@, already a source committer) as new ports committers. We also said goodbye to az@, brd@, dtekse@, eadler@, and johans@. The default versions of some ports changed: Lazarus is now at version 2.0.6, Samba at 4.10, and Python at 3.7. The web browsers received their updates too: Chromium is now at version 78.0.3904.108, Firefox at version 72.0 and its ESR counterpart at version 68.4.0. Finally, the Qt stack got updated to version 5.13.2. Some modernizations took place: the "palm" category was removed as well as the virtual "ipv6" category. IPv6 support (next to IPv4) is now considered the norm. Lastly, the CentOS 6 ports were removed after their CentOS 7 counterparts were made the default in the previous quarter. As always, antoine@ was happy to take your exp-runs, this time a total of 30, for various ports and framework updates, default version updates, and the removal of OpenJDK 6 and OpenJRE 6. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment, the art application https://kdenlive.org and hundreds of other applications that can be used on any FreeBSD desktop machine. The monthly releases of KDE Frameworks, bugfix-releases of KDE Plasma Desktop and the quarterly feature release of KDE Plasma Desktop were all landed in the ports tree shortly after upstream releases. There were also monthly KDE Applications bugfix-releases which also landed in a timely manner. Digikam landed a new release thanks to Dima Panov. We hope this gets rid of the instability caused by the previous release update from last quarter. The open bugs list grew to 32 this quarter with a handful of strange build failures. We welcome detailed bug reports and patches. KDE packaging updates are prepared in a copy of the ports repository on GitHub and then merged in SVN. We welcome pull requests there as well. __________________________________________________________________ Java on FreeBSD Links OpenJDK 11 repository at FreeBSD GitHub URL: https://github.com/freebsd/openjdk-jdk11u Contact: Greg Lewis During Q4 the FreeBSD java porting effort features smaller updates than those of the previous quarters. However, the following changes are worth mentioning: * Updated ports for OpenJDK 8u232, 11.0.5, and 13.0.1 * Removal of the EOL'ed Java 6, 9, and 10 ports * Fixed remote debugging for Java 11+ * Fixed a problem with running external processes for Java 11+ This project was sponsored by FreeBSD Foundation. __________________________________________________________________ Electron and VSCode Links Electron port URL: https://github.com/tagattie/FreeBSD-Electron VSCode port URL: https://github.com/tagattie/FreeBSD-VSCode Contact: Hiroki Tagato Contact: Luca Pizzamiglio Electron is a popular framework to build desktop application using JavaScript, HTML and CSS. Few months ago, electronjs has been added to the ports tree. Currently version 4.x and 6.x are supported. In the last quarter, a popular application, the powerful VSCode editor, has been added to the ports tree as well. VSCode is based on electron 6.x atom, another popular editor, is still a work in progress and it's based on electron 4.x Many thanks to Hiroki, for the hard work, and to Antoine, for support of the special poudriere configuration needed to build VSCode. __________________________________________________________________ Bastille Links Bastille GitHub URL: https://github.com/BastilleBSD/bastille Bastille Templates URL: https://gitlab.com/bastillebsd-templates Bastille Website URL: https://bastillebsd.org Contact: Christer Edwards What is Bastille? Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille uses FreeBSD jails as a container platform and adds template automation to create a Docker-like collection of containerized software. The template collection currently validates 30-40 applications from the ports tree, and is growing! Templates take care of installing, configuring, enabling, and starting the software, providing an automated way of building containerized stacks. Bastille is available in ports at sysutils/bastille. Q4 2019 Status In Q4 2019 Bastille published three releases (for a total of ten releases in 2019). Highlights from these updates include: * support for "thin" (shared base) and "thick" (unique base) jails * support for INCLUDE and FSTAB in template system * upgrade support for shared and unique base jails * GitLab CI/CD testing for all official templates * automatic template validation and CVE scan * dedicated pf table for private IP jails Bastille saw an increase in community contributions with six new GitHub contributors. These people generously improved error checking, release validation (sha256), firewall functionality, flexible networking and initial support for resource limits! We want to thank everyone that contributed to Bastille in 2019. Your support has been amazing! __________________________________________________________________ Universal Packaging Tool (upt) Links Upt repositories URL: https://framagit.org/upt/ Upt itself URL: https://framagit.org/upt/upt/ The FreeBSD backend URL: https://framagit.org/upt/upt-freebsd Contact: The upt mailing list Contact: <#upt-packaging> The Universal Package Manager (upt) is a tool designed to easily port software from common upstream package archives (such as https://rubygems.org/) to various operating systems, including FreeBSD, of course. A lot of similar tools already exist: pytoport (which creates FreeBSD ports for PyPI packages), gem2deb (which creates Debian packages from a Ruby gem), and many others. The main difference between these tools and upt is that the latter uses a modular design, allowing it to handle packages from many sources and support many different operating systems through plugins. You may try upt by installing sysutils/py-upt, sysutils/py-upt-pypi and sysutils/py-upt-freebsd. Suppose you would like to package "upt-cran", which is hosted on PyPI. You could do it like so: # upt package -f pypi -b freebsd -o /usr/ports/sysutils/ upt-cran $ tree /usr/ports/sysutils/py-upt-cran /usr/ports/sysutils/py-upt-cran |-- Makefile |-- distinfo `-- pkg-descr $ cat sysutils/py-upt-cran/Makefile # $FreeBSD: head/en_US.ISO8859-1/htdocs/news/status/report-2019-10-2019-12.xml 53827 2020-01-26 13:49:47Z trasz $ PORTNAME= upt-cran DISTVERSION= 0.1 CATEGORIES= sysutils python MASTER_SITES= CHEESESHOP PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} MAINTAINER= python@FreeBSD.org COMMENT= CRAN frontend for upt LICENSE= BSD3CLAUSE LICENSE_FILE= ${WRKSRC}/XXX RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}lxml>0:devel/py-lxml@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}requests>0:www/py-requests@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}upt>0:sysutils/py-upt@${PY_FLAVOR} TEST_DEPENDS= ${PYTHON_PKGNAMEPREFIX}requests-mock>0:www/py-requests-mock@${PY_FLAVOR } USES= python USE_PYTHON= autoplist distutils .include Note that the Rubygems and CPAN frontends are also available (sysutils/py-upt-rubygems and sysutils/py-upt-cpan). Bug reports and comments about this new tool are welcome. __________________________________________________________________ Wine on FreeBSD Links Wine homepage URL: https://www.winehq.org Contact: Gerald Pfeifer A lot has happened since our last quarterly report. The Wine 4 release series has been in our tree for nearly a year and proven rather stable. Both that port and wine-devel, which tracks bi-weekly development releases, have seen regular adjustments to infrastructure changes and small improvements, in particular also around non-default options. Now we need help! WoW64 (or Wine on Wine 64) allows running both 32-bit and 64-bit Windows applications in one installation. A volunteer has proposed * a general framework for lib32- companion libraries https://reviews.freebsd.org/D16830 * an approach directly using our Wine ports https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242625 to make this work and we do not have the expertise nor facilities to properly review, test, and maintain those ourselves. If you can facilitate getting (at least one of) these into the tree, please help! And if you'd like to assume co-maintainership or sole maintainership of emulators/wine*, that is an option, too. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. sysctlbyname-improved Links gitlab.com/alfix/sysctlbyname-improved URL: https://gitlab.com/alfix/sysctlbyname-improved Contact: Alfonso Sabato Siciliano The FreeBSD kernel maintains a Management Information Base (MIB) where a component (object) represents a parameter of the system. The sysctl() system call explores the MIB to find an object by its Object Identifier (OID) and calls its handler to get or set the value of the parameter. The sysctlbyname() syscall (or the old function) accepts the name of the object (instead of its OID) to identify it. The purpose of this project is to allow sysctlbyname() to handle: * a CTLTYPE_NODE with a no-NULL handler, example "kern.proc.pid.\"; * an object with some level-name equals to the '\0' character, example "security.jail.param.allow.mount."; A sysctlbyname() clone is provided: sysctlbyname_improved(), the implementation core is a new sysctl internal node to get the OID of a node by its name eventually expanded with an input for its handler; both, can be installed via _sysutils/sysctlbyname-improved-kmod_. The internal node is also used by the sysctlmif_oidinputbyname() function of the _devel/libsysctlmibinfo2_ userland library and can be handled by the SYSCTLINFO_BYNAME macro of the sysctlinfo interface (described in the previous quarterly status report). __________________________________________________________________ pot and the nomad pot driver Links Nomad pot driver URL: https://github.com/trivago/nomad-pot-driver Pot project URL: https://github.com/pizzamig/pot minipot URL: https://github.com/pizzamig/minipot Contact: Luca Pizzamiglio Contact: Esteban Barrios The pot utility added support to private bridges: a group of jail can now use a dedicated bridge, instead of the public one, improving isolation. Moreover, several small bugs have been found and fixed, and support to pre/post start/stop hook script has been added. The nomad pot driver received support for nomad restart without drain and improved configuration stability. A new port called minipot has been added: this port will install configuration files and dependencies, converting a FreeBSD machine in a single node cluster. It will install nomad, consul, pot, the nomad pot driver and traefik, already configured and ready to use. Experimental work has been done on a tool that allows to create and run pot images (FreeBSD jails) on other operating systems (Linux and Mac), adopting an approach similar to docker machine. We hope to make this tool available soon. Next steps: * add dual IP stack support to pot * add private bridge support to the nomad pot driver * improve usability to create images This project was sponsored by trivago N.V.. __________________________________________________________________ 7 Days Challenge Links 7 Days Challenge URL: https://wiki.freebsd.org/MichaelCrilly/7dayschallenge Contact: Michael Crilly The 7 Days Challenge is an educational initiative to help people onboard with FreeBSD more easily. It will use a combination of tutorials, guides and how-tos to get users engaged with FreeBSD quickly, target specific end goals the user might have for FreeBSD, and more. The primary objective is to demonstrate FreeBSD's capabilities as a modern, relevant operating system in today's Cloud centric, automated business models. This project was sponsored by OpsFactory Pty Ltd (Australia). __________________________________________________________________ NomadBSD Links NomadBSD Website URL: https://www.nomadbsd.org/ NomadBSD Github URL: https://www.github.com/NomadBSD/NomadBSD NomadBSD Developer Mailing List URL: https://www.freelists.org/list/nomadbsddevs Contact: NomadBSD Team NomadBSD is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or testing FreeBSD's hardware compatibility. After one release candidate the NomadBSD Team finished and released NomadBSD 1.3 on December 7th. This release is based on FreeBSD 12.1, fixed a lot of bugs and added new packages and features. Along those features are the option to install NomadBSD on ZFS and the use of an automatic configuration when running NomadBSD in VirtualBox. New tools developed by the NomadBSD Team and added to version 1.3 are nomadbsd-dmconfig to select a display manager theme, nomadbsd-adduser which adds new user accounts and DSBBg to change the background image. All these are using the Qt-Toolkit. In Q4 we added two mirrors in France and Germany and would like to thank nosheep.fr and fau.de for them. We are looking for people to help the project. Help is much appreciated in all areas: * Translation of program interfaces * Design artwork * Programming new tools, extend existing ones * Tests and Bug reports / UX and feature suggestions * Mirrors outside of Europe Open tasks: * Support installation on disk partitions and add a partition editor GUI. * Complete disk encryption * Add a user-friendly network manager From owner-freebsd-hackers@freebsd.org Wed Jan 29 09:26:37 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29B5F1D0BAA for ; Wed, 29 Jan 2020 09:26:37 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486ymD2wCMz4M2H for ; Wed, 29 Jan 2020 09:26:36 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x335.google.com with SMTP id s10so5398535wmh.3 for ; Wed, 29 Jan 2020 01:26:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition; bh=RCKXocqfLOjZt0H3yoS16zCUn9IleHKrapFxEjb+yZk=; b=aMJsgU1Jo+FUQjHQk3VfKd9whU+vYMjN3bPL0GgMFAlz3X7kIwZXFhjAiBy0GbN/NI opN1X0/h9hfzwD7WhP0H8uew5VcWpxiotS3S7fiVDoifdGmDnzvpHczebS4qbDLgiW/8 987PktFBZTF3Va+W20olFfVa8oXOcJCWCj4aDdERhSopYH+TgoGNRRWJkm40uKAS7xAx 7/1YOg0Kqi9q5FbLXqL6a/jL5aQS+nxu63PQYNWXcMDAWB2AsslxnHQk/PZvZba8JZbp 0E+5Nj7atFoH0VC16p8W1Nq5IT4N5M9dMx7ZzmXaoIDG6EY/oyCbLloB2ECMkS614g80 SyYw== X-Gm-Message-State: APjAAAXtqGgns9/vD0MugsYDhgm4RWCNxMgZS1/q/OWYm3MpXBPeSZ0O ub7hSaDmUOPka4wzpUgQGfP6Imxy X-Google-Smtp-Source: APXvYqxjipwzHeNCs16KOi/zQmEG2d7beC8t5G26RlKgOIsgX6E8UfDhh1Gufs9fleTVTJxKL8UK+w== X-Received: by 2002:a1c:7203:: with SMTP id n3mr10305599wmc.119.1580289993460; Wed, 29 Jan 2020 01:26:33 -0800 (PST) Received: from lion.0xfce3.net (p4FD3AEF0.dip0.t-ipconnect.de. [79.211.174.240]) by smtp.gmail.com with ESMTPSA id y20sm1508958wmi.25.2020.01.29.01.26.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 01:26:32 -0800 (PST) Sender: Gordon Bergling Date: Wed, 29 Jan 2020 10:26:31 +0100 From: Gordon Bergling To: freebsd-hackers@freebsd.org Subject: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200129092631.GA22505@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 10:18AM up 2 days, 20:25, 3 users, load averages: 4.08, 4.01, 3.12 X-Rspamd-Queue-Id: 486ymD2wCMz4M2H X-Spamd-Bar: / X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[googlemail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[240.174.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(0.00)[ip: (-9.07), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 09:26:37 -0000 Hi, I recently stumbled upon the default world readable permissons of /root and /etc/sysctl.conf. I think that it would be more secure to reduce the default permission for /root to 0700 and to 0600 for /etc/sysctl.conf. I prepared a differtial for the proposed change: https://reviews.freebsd.org/D23392 What do you think? Best regards, Gordon From owner-freebsd-hackers@freebsd.org Wed Jan 29 09:53:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AD9E1D1C54 for ; Wed, 29 Jan 2020 09:53:29 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 486zMD3tWDz4Njw for ; Wed, 29 Jan 2020 09:53:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x342.google.com with SMTP id f129so5697385wmf.2 for ; Wed, 29 Jan 2020 01:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=wh69OL8IPho9SExjH9U5WU/t69mlTJDwl9MWvmb37pM=; b=f3iwYzY7xaXjNGUA0/9QRtNzqW8F/mHwutkAPG3pM2aVVzX4BX6Cg4dq5uTejQffYJ 5RUNjnDCf1+H6RocrfwP1VG7n32TKm5iozpAM36ZlzTSwX/0VcAJS7xns3iaB3H5LZHn 50gJ34RfLz67L6s0NoLvi84k8VtNrdfEd/FjiKTd3rqrU5nJwWLKHe7kBlQIFKvw8gdo OgMztkpfuNpVEu22Xv+SRIp8yAR7acXCX+ddr5b79Irg2EAeHxgSnSuEC4ll7mVwfx7w bfFdBGCExeTOQntlQzpzl6UbBilfUu1UwtHhOTvxc1KGK96x2SgaMWG85UDN4hNYL11g g4SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=wh69OL8IPho9SExjH9U5WU/t69mlTJDwl9MWvmb37pM=; b=ahCUvNy/1HJuBqn/B8wxmI7F1PYRH20IaIIyw5nZzt2tH9Qu2z4a+uCg0iP4qZZ8Ev wHK8nmn0zSrQqAJTv7RXjx9YXWJCVFN7dFbgxjDoH5k/gILRnno9IZQIFQhKLxIM90xG a7iGR5msqTVDr/H3a+qZgLqXSDj/oYFs8ooJl41owD6CbhfdnPma3aseT5c2amW5w/4E vC8iX0J4tRnQcWYXg9j1F3ec4ETFShfU2goVgxxtRV4fa7lzm+DRaj38ZizoYiCe/gK2 ueus8i8y03ntLVYl4OZMi/kZW5p7/6S/tO2QuJmDQ2TxG1IJeif9/JlNbF5dgRU3zJsN YVbA== X-Gm-Message-State: APjAAAWtNnhhvbwED3+FA8zepsw6D2LhZh7S3pwUR3KqNUO9YSNXxAVz wZobZr3FtwOgXWwus/fetRbr0jqa X-Google-Smtp-Source: APXvYqyEXd8FJDDzatkxSQFT2oFssPr97+7pwAwf7FRcExkKPV34Nk7f37pvYbKZWKyCSOm9/PD2gA== X-Received: by 2002:a1c:ddc3:: with SMTP id u186mr10535718wmg.103.1580291606973; Wed, 29 Jan 2020 01:53:26 -0800 (PST) Received: from ernst.home (p5B02394F.dip0.t-ipconnect.de. [91.2.57.79]) by smtp.gmail.com with ESMTPSA id q14sm2127609wrj.81.2020.01.29.01.53.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 01:53:26 -0800 (PST) Date: Wed, 29 Jan 2020 10:53:25 +0100 From: Gary Jennejohn To: Gordon Bergling via freebsd-hackers Cc: Gordon Bergling Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200129105325.600cddc1@ernst.home> In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> References: <20200129092631.GA22505@lion.0xfce3.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 486zMD3tWDz4Njw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=f3iwYzY7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::342 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(0.00)[ip: (2.58), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[79.57.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[googlemail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 09:53:29 -0000 On Wed, 29 Jan 2020 10:26:31 +0100 Gordon Bergling via freebsd-hackers wrote: > Hi, > > I recently stumbled upon the default world readable permissons of /root and > /etc/sysctl.conf. I think that it would be more secure to reduce the default > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > I prepared a differtial for the proposed change: > https://reviews.freebsd.org/D23392 > > What do you think? > I think that changing the permissions on / would defeat the purpose of /etc/devd.conf and then adding users to certain groups in /etc/group to make devices usable without having to escalate to root rights. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Jan 29 10:25:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3F821D2979 for ; Wed, 29 Jan 2020 10:25:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48703g0dnyz4Q5M for ; Wed, 29 Jan 2020 10:25:02 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x344.google.com with SMTP id q9so5558509wmj.5 for ; Wed, 29 Jan 2020 02:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=lkFJTbnuBWw1TmFoblgrURi2X0F+/GETLSFM5vk5RGk=; b=ST4n8e7Wm7QGz2Q+uAs569j++/zeEmhqoTtc9D6AgBSB3eAnIkvAdA/qf+KM6e3Mxa u8+XT5ASbYWmp78niTN4UWke+H2NKupBNMFBckMmogITaM8BrwywvMu5lty8c15XqnsH P7xp131N5x1khVgc8L/r9yFGNSd7UX8/6xlmfjYBN2F/Y0+u3IL7CiqR2+nPN/XaWRuo hhRbqVxe6FciOl74OnS/tEIqmvsK1uu57ckFMNvqzUpZJKaqHwq1wBcKbKkzvJwGvX1A 8Xe2UMhwFNyPUut+D0fqG6WqqZbe4JRZ6CnUS/VlhPPwoiUlukALg2JzOOoa0O+T0FcB aNkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=lkFJTbnuBWw1TmFoblgrURi2X0F+/GETLSFM5vk5RGk=; b=KrDRd3siU6ow24uAnNLdeh/8Be8EaC7NaJXvmpNyEWDFbJN3OmR9Qh8DrDi7qZp3mx Xm9LV/gfJekt5gd62uPPjx8nJ5GL3iz0alQC5vh3NcidTLhpIF/CbQgnp+NBz1cZ+rK6 oXJe8tJdUj4oxP1L4iv3Sa8m91SwKQ+40wIH6UK9UTHoM3yLQvTyIj6dF5Paf7N9C0jt H4Se5yh8UZ6IoeEd2/KOLuvuXLdQdzsCex3fX9/3LRiCn8Vnl0rh4OVefKQeGXCkt2Sc sj84UVpErRNxWn62pCT+nN3woZKTuxI5gnnO4SNQ2ptf47G2ZKoE7Wm5krHmiE/LcPua 5xOw== X-Gm-Message-State: APjAAAXIaz0AQjz/m7gIDlVbjnaRufpNHaw1iC9AbPEBdjMrtJreEgS/ XfvTiqHzAk9Nh2P1XoaEcUm5A3q5 X-Google-Smtp-Source: APXvYqweXinpVyO64nTbSgZCUXfotuZaXy4i7w7Nr7qL5C8PRCN7t6pfvfEtPwH1/0IL/SJE6welIw== X-Received: by 2002:a1c:960c:: with SMTP id y12mr10642203wmd.9.1580293501302; Wed, 29 Jan 2020 02:25:01 -0800 (PST) Received: from ernst.home (p5B02394F.dip0.t-ipconnect.de. [91.2.57.79]) by smtp.gmail.com with ESMTPSA id q6sm2239631wrx.72.2020.01.29.02.25.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 02:25:00 -0800 (PST) Date: Wed, 29 Jan 2020 11:25:00 +0100 From: Gary Jennejohn To: Gordon Bergling via freebsd-hackers Cc: Gordon Bergling Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200129112500.368610e8@ernst.home> In-Reply-To: <20200129105325.600cddc1@ernst.home> References: <20200129092631.GA22505@lion.0xfce3.net> <20200129105325.600cddc1@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48703g0dnyz4Q5M X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ST4n8e7W; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::344 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(0.00)[ip: (2.56), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[79.57.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[googlemail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 10:25:03 -0000 On Wed, 29 Jan 2020 10:53:25 +0100 Gary Jennejohn wrote: > On Wed, 29 Jan 2020 10:26:31 +0100 > Gordon Bergling via freebsd-hackers wrote: > > > Hi, > > > > I recently stumbled upon the default world readable permissons of /root and > > /etc/sysctl.conf. I think that it would be more secure to reduce the default > > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > > > I prepared a differtial for the proposed change: > > https://reviews.freebsd.org/D23392 > > > > What do you think? > > > > I think that changing the permissions on / would defeat the purpose of > /etc/devd.conf and then adding users to certain groups in /etc/group > to make devices usable without having to escalate to root rights. > I decided to actually test this case, since I thought I should back up my opinion with some facts. So, I did chmod 700 / and rebooted. I wasn't able to login as a normal user because an error was raised about not being able to find the root for audit (or similar wording). After changing root back to 755 and remounting /home I could log in. Your idea may work if all filesystems are in one big partition, I can't really say, but on my system /, /var, /usr and /home are separate partitions/disks. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Jan 29 10:29:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F03A1D2C13 for ; Wed, 29 Jan 2020 10:29:49 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4870984p70z4QKn for ; Wed, 29 Jan 2020 10:29:48 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id g1so5583128wmh.4 for ; Wed, 29 Jan 2020 02:29:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iDWVKSDGGqi2IW4eJAyCNflDfCKx2jEBAYJrjiUzGKk=; b=PtLFWUuu9XmSqSBGt3cIo6tGF02xxh1VyKRapYOWfW9q72yUtuIgWxaXBSca1gXcc+ o1couHRc/wNwNN2mh1ZN1KxzG6iqof/cKln4Nb4T/ddCl7xVnFtnFMFZgrA+J+ibQWQS QQEgQxt93Jq5CHxYzlX8BnBW5qEcIm21QcLF5YXx6f8LBQlKjccyocr83ISGaraIcSYy 8N2P9l3air1M+W2lz7QrVBjVgXGQr3Jk4o3w0CuWo9nfhqSsBZTVYXDE7FWaNp286APN Q9VTfnoUG/mxN+MV5IwdNXgZhz4jUD2So6mVihxqtrk+5lBCC77+vhepN/0djK+DfDC5 29Fg== X-Gm-Message-State: APjAAAV/ZsE8N6uKq+TqJa5ZXgsLt284QELUHunaQNXXRm2TCe1qUnMv J7HqtUetI0LMyFK9MK56rezSS3Ph X-Google-Smtp-Source: APXvYqycQOjo5+hk79arSulFGyRE7FB7B2FT1ro9SpdNri/HLjIvYMiPiXgcQJOmsl9lIFFBtFyeLw== X-Received: by 2002:a1c:7f87:: with SMTP id a129mr3900227wmd.156.1580293785650; Wed, 29 Jan 2020 02:29:45 -0800 (PST) Received: from [10.0.1.114] (p4FD3AEF0.dip0.t-ipconnect.de. [79.211.174.240]) by smtp.gmail.com with ESMTPSA id c2sm2259926wrp.46.2020.01.29.02.29.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 02:29:45 -0800 (PST) Sender: Gordon Bergling From: Gordon Bergling Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: More secure permissions for /root and /etc/sysctl.conf Date: Wed, 29 Jan 2020 11:29:43 +0100 In-Reply-To: <20200129112500.368610e8@ernst.home> Cc: Gordon Bergling via freebsd-hackers To: Gary Jennejohn References: <20200129092631.GA22505@lion.0xfce3.net> <20200129105325.600cddc1@ernst.home> <20200129112500.368610e8@ernst.home> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 4870984p70z4QKn X-Spamd-Bar: / X-Spamd-Result: default: False [0.85 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; URI_COUNT_ODD(1.00)[3]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[240.174.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.953,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; NEURAL_HAM_LONG(-0.99)[-0.995,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.15), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 10:29:49 -0000 Gary, no, you are mistaken here. Not / it is /root the home folder of the = system administrator. # chmod 700 /root That is not /. Gordon > Am 29.01.2020 um 11:25 schrieb Gary Jennejohn : >=20 > On Wed, 29 Jan 2020 10:53:25 +0100 > Gary Jennejohn > = wrote: >=20 >> On Wed, 29 Jan 2020 10:26:31 +0100 >> Gordon Bergling via freebsd-hackers = wrote: >>=20 >>> Hi, >>>=20 >>> I recently stumbled upon the default world readable permissons of = /root and=20 >>> /etc/sysctl.conf. I think that it would be more secure to reduce the = default >>> permission for /root to 0700 and to 0600 for /etc/sysctl.conf. >>>=20 >>> I prepared a differtial for the proposed change: >>> https://reviews.freebsd.org/D23392 >>>=20 >>> What do you think? >>>=20 >>=20 >> I think that changing the permissions on / would defeat the purpose = of >> /etc/devd.conf and then adding users to certain groups in /etc/group >> to make devices usable without having to escalate to root rights. >>=20 >=20 > I decided to actually test this case, since I thought I should back up > my opinion with some facts. >=20 > So, I did chmod 700 / and rebooted. >=20 > I wasn't able to login as a normal user because an error was raised > about not being able to find the root for audit (or similar wording). >=20 > After changing root back to 755 and remounting /home I could log in. >=20 > Your idea may work if all filesystems are in one big partition, I > can't really say, but on my system /, /var, /usr and /home are > separate partitions/disks. >=20 > --=20 > Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Jan 29 10:36:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83AED1D3736 for ; Wed, 29 Jan 2020 10:36:41 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4870K457gmz4RFs for ; Wed, 29 Jan 2020 10:36:40 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id g17so19544469wro.2 for ; Wed, 29 Jan 2020 02:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=DBo85cdZYxNuZkKtJRCL2hmP4A5czyX1VpyviLVkLnM=; b=FmLBzEe/RKrZM16mORT/n1irM5X90gj4ZcZ4L23QW17KNrREI5IKmtLcyQ1SdAUfgO HmUT/wLSDrDnhxlLwXEBnmaH6zuCsTaZZ8i0DYGQCR2e40Afi8sNRGj6FMoxOUbcR7Gu MAp5/I52YAQ3LEDV9wTOcQzpR/c1aG+nW9HKw8pWwCBcOhrCSIHiPQoGbEKz3Lfxua10 O1rCTsFQzKoHOMO/ySUNg7MaTTiReX7VWGDGcwSB88XguW/Dtn9xkwYVOa/qcTuiGhfo TFJkkuPGBTNiMWedFDWRsiB3Acg0txLHjZide8pzVNla6x3zRxLXBupA9MVJiglOG61Y Y6UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=DBo85cdZYxNuZkKtJRCL2hmP4A5czyX1VpyviLVkLnM=; b=aTYc9rcnEqAJTdhC+K8NxKp2F7yGI3ndt7Ic49hJYFt3lLBh7f597m9+Ltu9wuDyjU uUmOTN8OwisUn5CMc4Si8vh47jWX+3Vu2zGZIbmlaaqTS5HjjNdd1mvHdaXGH8SSuhB/ sHL2F5G7LoOutd+jiIqqwFnAOg9jEUbAAdk+I1gIGDyFVeHldCz50hYuasVRN0xXkIEX Utd6HmjfEdFrl1twcCtU+df6sNtMkZRjIqFG6kht/a9YomdYdKVwYQzVjHypMVeHGeVT QX25BgZc/SMgkNktXbIDknnfQpaqtXuL2xyXrL8F17oJQ9EFbPNfSaviIT9+fwixLdY1 kz2w== X-Gm-Message-State: APjAAAWn1gQJvRyVc+6oLABqBD4KGwKyUo7X+IoTjAXUDd3zCBSDeu9+ 63unFENvoxr36vkUb9k1oogJ6SAa X-Google-Smtp-Source: APXvYqypn10rzAruw2Ptzwashp9vzOV84+rAPLpAqAVNde1PqzXDmg8cvgtkLtzeVwh768CwlKTJsQ== X-Received: by 2002:adf:a51d:: with SMTP id i29mr6965339wrb.119.1580294198785; Wed, 29 Jan 2020 02:36:38 -0800 (PST) Received: from ernst.home (p5B02394F.dip0.t-ipconnect.de. [91.2.57.79]) by smtp.gmail.com with ESMTPSA id z133sm1886858wmb.7.2020.01.29.02.36.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 02:36:38 -0800 (PST) Date: Wed, 29 Jan 2020 11:36:37 +0100 From: Gary Jennejohn To: Gordon Bergling via freebsd-hackers Cc: Gordon Bergling Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200129113637.128890a5@ernst.home> In-Reply-To: <20200129112500.368610e8@ernst.home> References: <20200129092631.GA22505@lion.0xfce3.net> <20200129105325.600cddc1@ernst.home> <20200129112500.368610e8@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4870K457gmz4RFs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FmLBzEe/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::444 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[79.57.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.74), ipnet: 2a00:1450::/32(-2.52), asn: 15169(-1.78), country: US(-0.05)]; FREEMAIL_CC(0.00)[googlemail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 10:36:41 -0000 On Wed, 29 Jan 2020 11:25:00 +0100 Gary Jennejohn wrote: > On Wed, 29 Jan 2020 10:53:25 +0100 > Gary Jennejohn wrote: > > > On Wed, 29 Jan 2020 10:26:31 +0100 > > Gordon Bergling via freebsd-hackers wrote: > > > > > Hi, > > > > > > I recently stumbled upon the default world readable permissons of /root and > > > /etc/sysctl.conf. I think that it would be more secure to reduce the default > > > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > > > > > I prepared a differtial for the proposed change: > > > https://reviews.freebsd.org/D23392 > > > > > > What do you think? > > > > > > > I think that changing the permissions on / would defeat the purpose of > > /etc/devd.conf and then adding users to certain groups in /etc/group > > to make devices usable without having to escalate to root rights. > > > > I decided to actually test this case, since I thought I should back up > my opinion with some facts. > > So, I did chmod 700 / and rebooted. > > I wasn't able to login as a normal user because an error was raised > about not being able to find the root for audit (or similar wording). > > After changing root back to 755 and remounting /home I could log in. > > Your idea may work if all filesystems are in one big partition, I > can't really say, but on my system /, /var, /usr and /home are > separate partitions/disks. > Never mind. Gordon explained what he really meant. That's what I get for not looking at the differential before responding. Sorry for wasting bandwidth here. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Jan 29 11:41:36 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D9ED1D4FC8 for ; Wed, 29 Jan 2020 11:41:36 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4871ly4FKSz4TnS for ; Wed, 29 Jan 2020 11:41:34 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id 00TBfUn0049279 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jan 2020 12:41:31 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1580298091; bh=94SgR6CCtuYdv4WGsv0J24Gh0HS/nnSFzdCd4fOo96Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VzvU5tUXtQKTzD0jfIpp6HTxQeqUe1uWPDv1D7/8aa9EUXbzJ1f7AypjIg9BU55HB EFfqPZsYda7Vv0UeXyKcSQFzY724ygjNl6LM9iXPpTLVMmuGaAea7mPziu0ZLH4ZCm kWOAuyMhG38tE9BkYJvihmaIkyO08Bs6gAs11z8Q= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id 00TBfUqP049276; Wed, 29 Jan 2020 12:41:30 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Wed, 29 Jan 2020 12:41:30 +0100 (CET) From: Wojciech Puchar To: Gordon Bergling cc: freebsd-hackers@freebsd.org Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> Message-ID: References: <20200129092631.GA22505@lion.0xfce3.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4871ly4FKSz4TnS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=puchar.net header.s=default header.b=VzvU5tUX; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.61)[ip: (-6.89), ipnet: 194.1.144.0/24(-3.45), asn: 43476(-2.76), country: PL(0.07)]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 11:41:36 -0000 > /etc/sysctl.conf. I think that it would be more secure to reduce the default > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. fully agree. i do it manually every time i build new system to create tarfiles > > I prepared a differtial for the proposed change: > https://reviews.freebsd.org/D23392 > > What do you think? > > Best regards, > > Gordon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Wed Jan 29 12:04:43 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE7ED1D6631 for ; Wed, 29 Jan 2020 12:04:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (107-204-234-170.lightspeed.sntcca.sbcglobal.net [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4872Gf5S2Fz4WVf for ; Wed, 29 Jan 2020 12:04:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id 00TC4YG7043097; Wed, 29 Jan 2020 12:04:34 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id 00TC4Yps043096; Wed, 29 Jan 2020 04:04:34 -0800 (PST) (envelope-from david) Date: Wed, 29 Jan 2020 04:04:34 -0800 From: David Wolfskill To: Gordon Bergling , Wojciech Puchar Cc: freebsd-hackers@freebsd.org Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200129120434.GM1270@albert.catwhisker.org> Reply-To: hackers@freebsd.org Mail-Followup-To: hackers@freebsd.org, Gordon Bergling , Wojciech Puchar , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cwsYEqkeH/7hgYPp" Content-Disposition: inline In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> X-Rspamd-Queue-Id: 4872Gf5S2Fz4WVf X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-6.92 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[hackers@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; TO_DN_SOME(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.52)[ip: (-9.59), ipnet: 107.192.0.0/12(-4.80), asn: 7018(1.86), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 12:04:43 -0000 --cwsYEqkeH/7hgYPp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 29, 2020 at 10:26:31AM +0100, Gordon Bergling via freebsd-hacke= rs wrote: > Hi, >=20 > I recently stumbled upon the default world readable permissons of /root a= nd=20 > /etc/sysctl.conf. I think that it would be more secure to reduce the defa= ult > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. >=20 > I prepared a differtial for the proposed change: > https://reviews.freebsd.org/D23392 >=20 > What do you think? >=20 > Best regards, >=20 > Gordon > ... On Wed, Jan 29, 2020 at 12:41:30PM +0100, Wojciech Puchar wrote: > ... > fully agree. i do it manually every time i build new system to create > tarfiles > .... For counterpoint, as well as a reminder of the "tools, not policy" catchphrase, I disagree, as I believe that doing so would increase the frequency of a need to escalate privilege merely to read (e.g.) configuration information that is not particularly "secret." For example, I have encountered systems where the administrator had /etc/rc.conf not-world-readable; I was needing to obtain root privilege way too often just to read the file... thus, for merely testing a new rc.d script (in a mode where it would merely report what it would have otherwise done). I submit that this does rather the opposite of "enhancing" security. I have no objection to providing a knob to adjust such a thing for a local configuration, and folks who want it can select it, while those who don't, need not do so. Peace, david --=20 David H. Wolfskill david@catwhisker.org "Now, with me, there's no lying." -- Donald J. Trump ["??!?" -- me] See http://www.catwhisker.org/~david/publickey.gpg for my public key. --cwsYEqkeH/7hgYPp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl4xdNJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcmlywf/Ric2wMLSw6DOUd1vFBjnTSpsputOATqvmyadX4wT01vrgfj/nuNr0pLW eTNSOmazjs7rtlVDCWupwaKxstWhqN4jYtaH5Qj03EHAB6IMUjJK+7dxHsB/krfA Do516WjfBsbTcnnzhMIdkyllYi09ASDIVdcT8BLyUaFnE25AdM4Xr1erSABeXjRj 7xwA/h7tDnfRLGF17fl5vEeXdS3/FdMokxY5DBfQcKgBxu6kDPyIDcmaaDSGYSWu RJHN4PSfKIQ3N1zupJBoN/zAIFzx1Mwg/tcnUE69PcIkPZAPHxEjWIbCIun+Hw5M yvOJpRZpY9SbXCVywtxF6dXfVl6Itg== =qPRS -----END PGP SIGNATURE----- --cwsYEqkeH/7hgYPp-- From owner-freebsd-hackers@freebsd.org Wed Jan 29 15:15:48 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0A0F1F2E42 for ; Wed, 29 Jan 2020 15:15:48 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4876W76BjKz3CYw for ; Wed, 29 Jan 2020 15:15:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qk1-x735.google.com with SMTP id q15so10892494qki.2 for ; Wed, 29 Jan 2020 07:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U9PkgequjbiUCpSetRyiwNWCyC0F11s0uguvxkmzjzM=; b=EIdOzNOF9IXyFVcLXlT+fvne2SjVQgb/wYx/JR3MuBnWWdXRTc71IwcuUmJKZTNm/r blwaNqRVn1t0RptDp+/nEGzzydOFxGZMzws8tsad97sVZ6LP0NTfbakaRcART0ao128T lwsvIOqwmeishSWYZu5+HFMCx4k2yASEh+3Br3rK0+EZAmZFtVj4gkngslCcw8IVH8QN RmGxc1DioZyA0suTSCu2Wi2h5UVnX+K4nVOyBS1MMQxlk6Hbng6SWCSdqPGS0BCF8Lvv 1d+eDGhvwTMVvZbhofxKsW+DEHb9BlrAxXbNRDTWZwbgZERNlfETXIeiQawJI9xvl16Y SxNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U9PkgequjbiUCpSetRyiwNWCyC0F11s0uguvxkmzjzM=; b=BJNM0C0bGd1xP/XleYN8rNwTKYm2QqjB7Q5DtvzZRcAE0rhi4rzNPDS7zxGbjEZH6u QJVTNoT81Vnr0HKA/dx92Q3+iQfwh93ao3UWjmvT33YeRTs+Lwl+RmBZm8y3BCO5rbGZ FTpvdfllcDnc9/vjAi/h5aozEfCK6Ey52yGce4V3beyu1i188VSnkEwzKmR/Q2Lv8Wof 58nIdFraZA7yWsbgFbjaY3j3Bm1dA/3hnVvzFbILgxj3fTZ4y61Dfk3XDPRARLde78vT ZhQSEn3E1wjF6Fp93SVRjE2XS+uPZwZ5QoNaE85tBKMXT45yicpOSbvci34E1QB4+Nx3 aKlw== X-Gm-Message-State: APjAAAUBmBd1d0+hVAbhkmNnMdPSUxUfWuT9w8cgk0ZqiSL6F/Eja7F7 Mi2TXBpRR+fz0B9S0OU8ay4Uqc7EMKKnkZH3Eis= X-Google-Smtp-Source: APXvYqzcl/8kGK3TpILB3vjDSgJlCKX+mBIhA6AJYSzFRo5vUcrMlcXx4VfWcI3wafvCv91o47N7c14ZIM881JxW7nw= X-Received: by 2002:a37:9a58:: with SMTP id c85mr111212qke.478.1580310946882; Wed, 29 Jan 2020 07:15:46 -0800 (PST) MIME-Version: 1.0 References: <20200129092631.GA22505@lion.0xfce3.net> In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> From: Ryan Stone Date: Wed, 29 Jan 2020 10:15:35 -0500 Message-ID: Subject: Re: More secure permissions for /root and /etc/sysctl.conf To: Gordon Bergling Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4876W76BjKz3CYw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EIdOzNOF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::735 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[5.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-9.31), ipnet: 2607:f8b0::/32(-2.03), asn: 15169(-1.78), country: US(-0.05)]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 15:15:48 -0000 On Wed, Jan 29, 2020 at 4:26 AM Gordon Bergling via freebsd-hackers wrote: > > Hi, > > I recently stumbled upon the default world readable permissons of /root and > /etc/sysctl.conf. I think that it would be more secure to reduce the default > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. I don't see the point in making this change to sysctl.conf. sysctls are readable by any user. Hiding the contents of sysctl.conf does not prevent unprivileged users from seeing what values have been changed from the defaults; it merely makes it more tedious. From owner-freebsd-hackers@freebsd.org Wed Jan 29 15:51:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB3791F43AE; Wed, 29 Jan 2020 15:51:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4877JK4qGvz3GFL; Wed, 29 Jan 2020 15:51:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id wpciiNwIJRnrKwpckijxXf; Wed, 29 Jan 2020 08:51:27 -0700 X-Authority-Analysis: v=2.3 cv=L7FjvNb8 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=Jdjhy38mL1oA:10 a=JAf30KXuAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=i9kqQ80-g474GPHsoRkA:9 a=QEXdDO2ut3YA:10 a=GEL62FyrTCmHtEug2d3R:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from Resas-iPad.esitwifi.local (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 215BF2C9; Wed, 29 Jan 2020 07:51:24 -0800 (PST) Date: Wed, 29 Jan 2020 07:50:57 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20200129120434.GM1270@albert.catwhisker.org> References: <20200129120434.GM1270@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: More secure permissions for /root and /etc/sysctl.conf To: hackers@freebsd.org, David Wolfskill , Gordon Bergling , Wojciech Puchar CC: freebsd-hackers@freebsd.org From: Cy Schubert Message-ID: <81E5B24A-BC03-4018-BED9-177071DE702A@cschubert.com> X-CMAE-Envelope: MS4wfChZH0h7PWLS2HxUNc0sut85gCUl6Z2BjFjCemgdYQ9MhlkUWMEbuoPrlgw6EdKaOAs8tFCA0Fu7TLmgJQm4uba1wXG4yrn76oS0JSvRGfhMBp5Dyimp pjfbaYAyX6uYSPrPlLgilDeI0w8qauYH8U4oiIP0sEbjYEOMmXTUEGHTltYi3qfmgqiYFYyo7JPEPiZFHhuub6HRs5gPtTsSi0OucF7jBOZSp/Y0HkbifHI7 NzBQD8RXDhDptiRs3nTHiaPrAZchxi2U864mal6Hr4nRg18B+kXHWnfnTV3lsMNeH1/leaeL8XWUJflgJd+Djw== X-Rspamd-Queue-Id: 4877JK4qGvz3GFL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.59 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[233.154.66.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.39)[ip: (-6.18), ipnet: 64.59.128.0/20(-3.19), asn: 6327(-2.48), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 15:51:30 -0000 On January 29, 2020 4:04:34 AM PST, David Wolfskill wrote: >On Wed, Jan 29, 2020 at 10:26:31AM +0100, Gordon Bergling via >freebsd-hackers wrote: >> Hi, >>=20 >> I recently stumbled upon the default world readable permissons of >/root and=20 >> /etc/sysctl=2Econf=2E I think that it would be more secure to reduce th= e >default >> permission for /root to 0700 and to 0600 for /etc/sysctl=2Econf=2E >>=20 >> I prepared a differtial for the proposed change: >> https://reviews=2Efreebsd=2Eorg/D23392 >>=20 >> What do you think? >>=20 >> Best regards, >>=20 >> Gordon >> =2E=2E=2E > >On Wed, Jan 29, 2020 at 12:41:30PM +0100, Wojciech Puchar wrote: >> =2E=2E=2E >> fully agree=2E i do it manually every time i build new system to create >> tarfiles >> =2E=2E=2E=2E > >For counterpoint, as well as a reminder of the "tools, not policy" >catchphrase, I disagree, as I believe that doing so would increase the >frequency of a need to escalate privilege merely to read (e=2Eg=2E) >configuration information that is not particularly "secret=2E" > >For example, I have encountered systems where the administrator had >/etc/rc=2Econf not-world-readable; I was needing to obtain root privilege >way too often just to read the file=2E=2E=2E thus, for merely testing a n= ew >rc=2Ed script (in a mode where it would merely report what it would have >otherwise done)=2E I submit that this does rather the opposite of >"enhancing" security=2E > >I have no objection to providing a knob to adjust such a thing for a >local configuration, and folks who want it can select it, while those >who don't, need not do so=2E > >Peace, >david The CIS benchmark doesn't specify /root or home directory permissions how= ever it does say umask must be 027 or better for all users=2E IMO reviewing the CIS benchmark would be the first place to start=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-hackers@freebsd.org Wed Jan 29 21:34:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C8AA11FF8BF for ; Wed, 29 Jan 2020 21:34:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487GwP6yKMz4DNZ for ; Wed, 29 Jan 2020 21:34:45 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00TLYc0Y066113; Wed, 29 Jan 2020 13:34:38 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00TLYce8066112; Wed, 29 Jan 2020 13:34:38 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001292134.00TLYce8066112@gndrsh.dnsmgr.net> Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> To: Gordon Bergling Date: Wed, 29 Jan 2020 13:34:38 -0800 (PST) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 487GwP6yKMz4DNZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.47)[-0.469,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.36)[0.362,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 21:34:46 -0000 > Hi, > > I recently stumbled upon the default world readable permissons of /root and > /etc/sysctl.conf. I think that it would be more secure to reduce the default > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. Those values are over kill, you really want to stop group wheel from reading these? At most they should be 0750 and 0640, and even that seems overboard. If your stroring highly secure stuff in /root your probably doing some thing wrong anyway. This appears to be security through obscurity based conservatism with no given attack vector of some form. Others have made good points as well. This also appears to be changing a default that would lead to many people unchanging it simply so a few that do change it can impose there defaults. > > I prepared a differtial for the proposed change: > https://reviews.freebsd.org/D23392 > > What do you think? Bad idea? > > Best regards, > > Gordon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Jan 29 23:52:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C8341FC779 for ; Wed, 29 Jan 2020 23:52:10 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 487Kyx3zLHz4NK7 for ; Wed, 29 Jan 2020 23:52:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7B97.dip0.t-ipconnect.de [93.219.123.151]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 00TNpxQA094051 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jan 2020 00:52:06 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 00TNpwpH081361; Thu, 30 Jan 2020 00:51:58 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 00TNpcBP019156; Thu, 30 Jan 2020 00:51:48 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202001292351.00TNpcBP019156@fire.js.berklix.net> cc: "Rodney W. Grimes" cc: Gordon Bergling To: freebsd-hackers@freebsd.org Subject: Re: More secure permissions for /root and /etc/sysctl.conf From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Wed, 29 Jan 2020 13:34:38 -0800." <202001292134.00TLYce8066112@gndrsh.dnsmgr.net> Date: Thu, 30 Jan 2020 00:51:38 +0100 X-Rspamd-Queue-Id: 487Kyx3zLHz4NK7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [2.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MULTIPLE_UNIQUE_HEADERS(0.70)[Cc]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.69)[0.686,0]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.64)[0.642,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; FREEMAIL_CC(0.00)[googlemail.com]; IP_SCORE(0.00)[ip: (0.03), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.01), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[151.123.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 23:52:10 -0000 "Rodney W. Grimes" wrote: > > Hi, > > > > I recently stumbled upon the default world readable permissons of /root and > > /etc/sysctl.conf. I think that it would be more secure to reduce the default > > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > Those values are over kill, you really want to stop group wheel from > reading these? At most they should be 0750 and 0640, and even that > seems overboard. > > If your stroring highly secure stuff in /root your probably doing some > thing wrong anyway. > > This appears to be security through obscurity based conservatism with > no given attack vector of some form. > > Others have made good points as well. This also appears to be changing > a default that would lead to many people unchanging it simply so a few > that do change it can impose there defaults. > > > > > > I prepared a differtial for the proposed change: > > https://reviews.freebsd.org/D23392 > > > > What do you think? > > Bad idea? Agreed, too tight. Over tightening tempts local fast reflex loosening by installers, with risk of over loosening if in a rush. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ UK stole 750,000 Brexit votes from Brits in EU + 3 M globaly. 170 states vote abroad. UK urged Brits in EU to foreign nationality http://stolenvotes.uk From owner-freebsd-hackers@freebsd.org Thu Jan 30 09:36:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02CF5232F46 for ; Thu, 30 Jan 2020 09:36:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487Zwm2T1qz3PNM for ; Thu, 30 Jan 2020 09:36:08 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id 00U9a4cD033670 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jan 2020 10:36:04 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1580376964; bh=1Iinbhwi3o5bQkT2DjApVS1Qq+Kha/zu7pywEWiaXTU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RidBn2rblVwP9x926dUJleChof0OCzShyWDumLEh7smySJA8LLsOvgP09RIhQOZhB 2wYAu3LB1IxYJYqWwJ5uIJVDTeQDLttswjD3iR+hP7YhEifHSM2W9HOu7aFhqnrx4S +fjmWtsVJK2owhM9r4OBXqdb/gdpAbQvHIHSkH8w= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id 00U9a4FW033667; Thu, 30 Jan 2020 10:36:04 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 30 Jan 2020 10:36:04 +0100 (CET) From: Wojciech Puchar To: Ryan Stone cc: Gordon Bergling , FreeBSD Hackers Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: Message-ID: References: <20200129092631.GA22505@lion.0xfce3.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 487Zwm2T1qz3PNM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=puchar.net header.s=default header.b=RidBn2rb; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.60)[ip: (-6.86), ipnet: 194.1.144.0/24(-3.43), asn: 43476(-2.75), country: PL(0.07)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FREEMAIL_CC(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 09:36:10 -0000 On Wed, 29 Jan 2020, Ryan Stone wrote: > On Wed, Jan 29, 2020 at 4:26 AM Gordon Bergling via freebsd-hackers > wrote: >> >> Hi, >> >> I recently stumbled upon the default world readable permissons of /root and >> /etc/sysctl.conf. I think that it would be more secure to reduce the default >> permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > I don't see the point in making this change to sysctl.conf. sysctls > are readable by any user. Hiding the contents of sysctl.conf does not > prevent unprivileged users from seeing what values have been changed > from the defaults; it merely makes it more tedious. true. but /root should be root only readable From owner-freebsd-hackers@freebsd.org Thu Jan 30 14:42:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D354123B562 for ; Thu, 30 Jan 2020 14:42:39 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from smtp.savba.sk (smtp.savba.sk [147.213.1.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487jkQ5fzDz4BdR for ; Thu, 30 Jan 2020 14:42:38 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from [192.168.1.80] (fire.quniverse.sk [147.213.112.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fyziprap) by smtp.savba.sk (Postfix) with ESMTPSA id 8DBD955890 for ; Thu, 30 Jan 2020 15:42:31 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Message-Id: Date: Thu, 30 Jan 2020 15:42:31 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 487jkQ5fzDz4BdR X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.rapcan@savba.sk designates 147.213.1.2 as permitted sender) smtp.mailfrom=peter.rapcan@savba.sk X-Spamd-Result: default: False [4.83 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:147.213.1.0/27]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.942,0]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MV_CASE(0.50)[]; NEURAL_SPAM_LONG(0.99)[0.986,0]; DMARC_NA(0.00)[savba.sk]; IP_SCORE(1.70)[ipnet: 147.213.0.0/16(4.48), asn: 2607(3.93), country: SK(0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2607, ipnet:147.213.0.0/16, country:SK]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 14:42:39 -0000 Hi, Is there a way to tell gptzfsboot NOT to analyze other disks (or specify = which disks to analyze)? (My system is on PATA disk(s) while the data = disks are SATA, hence there is no use to probe the SATA disks to search = for a bootable system). I am asking this to get around the following problem (bug?) I = encountered (tried both freeBSD 12.1 and freeNAS [11.2-U4 though = 11.3-RC2]):=20 When booting, I get "gptzfsboot: error 128 lba some_block_number" errors = in the phase when gptzfsboot is probing my data HDDs (on which there is = no bootloader, nor system, the drives can be even empty, with or without = a partition table).=20 The system boots eventually but the boot takes cca N x 7 minutes, where = N is the number of data disks gptzfsboot is trying to analyze (there are = several gptzfsboot: error 128 lba some_block_number lines per disk and = each takes some time to appear). Note: installer CD boots the installer system just fine. Also, once the = system is installed, and the system has booted from HDD (this takes ~30 = minutes with multiple gptzfsboot: error 128 lba some_block_number for = each disk) the system works just fine, including the very same data = disks that "produce" the errors.=20 Anyway, should this be reported as a bug? Any help is greatly appreciated. Cheers, --Peter P.S.: When putting the drives in another PC, the behavior is the same, = only gptzfsboot: error 128 lba some_block_number becomes gptzfsboot: = error 32 [if I remember the number correctly] lba some_block_number.= From owner-freebsd-hackers@freebsd.org Thu Jan 30 14:49:14 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D557823B7B4 for ; Thu, 30 Jan 2020 14:49:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 487jt20fqQz4C4p for ; Thu, 30 Jan 2020 14:49:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id v25so2636821qto.7 for ; Thu, 30 Jan 2020 06:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R5Hj7GpsyT3Niesq8QX8mr+5KQ0N4mCNCScpCn04iTg=; b=eP2eUprG6PDVJR53Ys/kXqWM2YoTqOGwALMPKAlfoMcEsLRqFe4hj5ye+hlwLjiNSy F5WGn3HnZYo61bAFjJc9VtLiqGGY7ZVaTw20dizahKZO5oW0eU0AuBx/8oW3oKw7OuTF z2ZBHkPJojDci0E/pUAr6uG+GdApkgIaUNG4COvCy7cxx+9nmVaIXX3ywyRTXyKDhnRl hcAPU919JUTZlHOJZHDXqbqKWsi8jzWWJVehS618tBQ+XaGiQvkBmwxDTJNdp5VVvGTN /p0xrS2WJ3mmRs4OpNuOZ4bgGmScYEkM1qLNIcS3ukSuNXeTPm8iQ+tMzfR0bb93v1ni yv/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R5Hj7GpsyT3Niesq8QX8mr+5KQ0N4mCNCScpCn04iTg=; b=RleElg6GxQRnZit/kK0CtKnQYfiA2g0i4OdnXnDmyDGnVoiVoMVAdbu1zGktkgl+JF LUVoAN+AcPdPUtW/Ggyzop2HHdwhjb63Wo2piHc2Ehls6LYk1MP8//Ouf/BJpOeAjFml UCKnWpSiv48hWBE/hucmPoXMpFVKDiQbR/eySZvyw3EYiOhyvECgZIP2tlvHbBcq6LP0 1dXH2Ep3QOd841FSh0+GgwYF4qHFi5Tiy2iR6IpkSENNWm87lw9j19TChOAdaJUbIphP MC3sFhl/dx3+/E5mGkbpQGOprL2Ull4LKFfvqnzalrnJBVCUaVcQe+MH6osOV7Rox9OE AJcw== X-Gm-Message-State: APjAAAUNGPa7oY/+dWdochf2htM0hLLOTY7/tbwbFYt2+GFT7uLhlXIW 50LsAh+Od1kVzFOj591cds/tk92li9YTEwFHdJb6ajfy X-Google-Smtp-Source: APXvYqxxJh8LCQ2h+6KXTOVVufTza62Mn+oC78JxYcryXFU4PlDh5MZyLnz7BYiHdbM4ztV16HF6FOFhS5e0tHkv5Qc= X-Received: by 2002:ac8:1aa6:: with SMTP id x35mr4984829qtj.32.1580395753059; Thu, 30 Jan 2020 06:49:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 30 Jan 2020 07:49:02 -0700 Message-ID: Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? To: =?UTF-8?Q?Peter_Rap=C4=8Dan?= Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 487jt20fqQz4C4p X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=eP2eUprG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.63 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.64)[ip: (-9.32), ipnet: 2607:f8b0::/32(-2.03), asn: 15169(-1.78), country: US(-0.05)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 14:49:14 -0000 On Thu, Jan 30, 2020 at 7:42 AM Peter Rap=C4=8Dan w= rote: > Hi, > > Is there a way to tell gptzfsboot NOT to analyze other disks (or specify > which disks to analyze)? (My system is on PATA disk(s) while the data dis= ks > are SATA, hence there is no use to probe the SATA disks to search for a > bootable system). > > I am asking this to get around the following problem (bug?) I encountered > (tried both freeBSD 12.1 and freeNAS [11.2-U4 though 11.3-RC2]): > When booting, I get "gptzfsboot: error 128 lba some_block_number" errors > in the phase when gptzfsboot is probing my data HDDs (on which there is n= o > bootloader, nor system, the drives can be even empty, with or without a > partition table). > The system boots eventually but the boot takes cca N x 7 minutes, where N > is the number of data disks gptzfsboot is trying to analyze (there are > several gptzfsboot: error 128 lba some_block_number lines per disk and ea= ch > takes some time to appear). > Short of hacking the code, there's really no way to do this. It's a feature that it finds all the disks in the pool so we can boot off zraid. > Note: installer CD boots the installer system just fine. Also, once the > system is installed, and the system has booted from HDD (this takes ~30 > minutes with multiple gptzfsboot: error 128 lba some_block_number for ea= ch > disk) the system works just fine, including the very same data disks that > "produce" the errors. > > Anyway, should this be reported as a bug? > You should report this as a feature request. It's not a bug, per se, because we need to look for multiple drives in many cases. If you want it to only look at the one disk that the boot loader was loaded from, that would be your ask. The other ask is to be more tolerant of this situation. A 7 minute lag to probe a single drive is 7 minutes too long... That's clearly some kind of bug, but without poking at your system in more detail, it's hard to know for sure. Warner > Any help is greatly appreciated. > > > Cheers, --Peter > > > P.S.: When putting the drives in another PC, the behavior is the same, > only gptzfsboot: error 128 lba some_block_number becomes gptzfsboot: erro= r > 32 [if I remember the number correctly] lba some_block_number. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Thu Jan 30 15:09:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7872023C05D for ; Thu, 30 Jan 2020 15:09:32 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from smtp.savba.sk (smtp.savba.sk [147.213.1.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487kKR3KqCz4DJX for ; Thu, 30 Jan 2020 15:09:31 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from [192.168.1.80] (fire.quniverse.sk [147.213.112.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fyziprap) by smtp.savba.sk (Postfix) with ESMTPSA id D3AB255890; Thu, 30 Jan 2020 16:09:29 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Message-Id: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Date: Thu, 30 Jan 2020 16:09:29 +0100 In-Reply-To: Cc: "freebsd-hackers@freebsd.org" To: Warner Losh References: X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 487kKR3KqCz4DJX X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.rapcan@savba.sk designates 147.213.1.2 as permitted sender) smtp.mailfrom=peter.rapcan@savba.sk X-Spamd-Result: default: False [5.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:147.213.1.0/27:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[savba.sk]; NEURAL_SPAM_MEDIUM(1.00)[0.998,0]; URI_COUNT_ODD(1.00)[7]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000,0]; IP_SCORE(1.68)[ipnet: 147.213.0.0/16(4.38), asn: 2607(3.93), country: SK(0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:2607, ipnet:147.213.0.0/16, country:SK]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:09:32 -0000 Thanks for your reply! I believe it is some kind of bug (maybe related to to = https://forums.freebsd.org/threads/gptzfsboot-error-128-after-adding-new-d= isks.65677/ but the solution provided there makes no difference in my = case). The funny thing is that the same system with the same type of disks = worked before (with 3 data HDDS and freeNAS [11.2-Ux]) there were no = gptzfsboot errors and the boot time was fast. After I added a 4th data = drive and upgraded the system (freeNAS) to new version, only then I = started getting the "gptzfsboot: error 128 lba some_block_number=E2=80=9D = errors. However I was not able revert to the state without the errors, = altough I tried the original version of freeNAS, with 3, 2, or 1 data = HDD(s), I tried wiping the HDDS, removing the partition table, creating = a new one, etc=E2=80=A6. I even tried installing freeBSD instead of = freeNAS :-). I am new to freeBSD=E2=80=A6 could you perhaps give me some advice how = to troubleshoot this error? Best, Peter > On 30 Jan 2020, at 15:49, Warner Losh wrote: >=20 >=20 >=20 > On Thu, Jan 30, 2020 at 7:42 AM Peter Rap=C4=8Dan = > wrote: > Hi, >=20 > Is there a way to tell gptzfsboot NOT to analyze other disks (or = specify which disks to analyze)? (My system is on PATA disk(s) while the = data disks are SATA, hence there is no use to probe the SATA disks to = search for a bootable system). >=20 > I am asking this to get around the following problem (bug?) I = encountered (tried both freeBSD 12.1 and freeNAS [11.2-U4 though = 11.3-RC2]):=20 > When booting, I get "gptzfsboot: error 128 lba some_block_number" = errors in the phase when gptzfsboot is probing my data HDDs (on which = there is no bootloader, nor system, the drives can be even empty, with = or without a partition table).=20 > The system boots eventually but the boot takes cca N x 7 minutes, = where N is the number of data disks gptzfsboot is trying to analyze = (there are several gptzfsboot: error 128 lba some_block_number lines per = disk and each takes some time to appear). >=20 > Short of hacking the code, there's really no way to do this. It's a = feature that it finds all the disks in the pool so we can boot off = zraid. > =20 > Note: installer CD boots the installer system just fine. Also, once = the system is installed, and the system has booted from HDD (this takes = ~30 minutes with multiple gptzfsboot: error 128 lba some_block_number = for each disk) the system works just fine, including the very same data = disks that "produce" the errors.=20 >=20 > Anyway, should this be reported as a bug? >=20 > You should report this as a feature request. It's not a bug, per se, = because we need to look for multiple drives in many cases. If you want = it to only look at the one disk that the boot loader was loaded from, = that would be your ask. >=20 > The other ask is to be more tolerant of this situation. A 7 minute lag = to probe a single drive is 7 minutes too long... That's clearly some = kind of bug, but without poking at your system in more detail, it's hard = to know for sure. >=20 > Warner > =20 > Any help is greatly appreciated. >=20 >=20 > Cheers, --Peter >=20 >=20 > P.S.: When putting the drives in another PC, the behavior is the same, = only gptzfsboot: error 128 lba some_block_number becomes gptzfsboot: = error 32 [if I remember the number correctly] lba some_block_number. > _______________________________________________ > freebsd-hackers@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers = > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org = " From owner-freebsd-hackers@freebsd.org Thu Jan 30 15:31:09 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39B6C23C94B for ; Thu, 30 Jan 2020 15:31:09 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp10.server.rpi.edu (smtp10.server.rpi.edu [128.113.2.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "canit.localdomain", Issuer "canit.localdomain" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 487kpN4GRxz4FY9 for ; Thu, 30 Jan 2020 15:31:08 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp-auth2.server.rpi.edu (route.canit.rpi.edu [128.113.2.232]) by smtp10.server.rpi.edu (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 00UFV5Qe054818 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 10:31:05 -0500 Received: from smtp-auth2.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth2.server.rpi.edu (Postfix) with ESMTP id D50371A090; Thu, 30 Jan 2020 10:31:04 -0500 (EST) Received: from [172.16.67.1] (gilead-qc124.netel.rpi.edu [128.113.124.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth2.server.rpi.edu (Postfix) with ESMTPSA id C40541A089; Thu, 30 Jan 2020 10:31:04 -0500 (EST) From: "Garance A Drosehn" To: "Gordon Bergling" Cc: freebsd-hackers@freebsd.org Subject: Re: More secure permissions for /root and /etc/sysctl.conf Date: Thu, 30 Jan 2020 10:31:03 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: <5DBC355C-0F87-4536-B418-A570504D2FD5@rpi.edu> In-Reply-To: <20200129092631.GA22505@lion.0xfce3.net> References: <20200129092631.GA22505@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 10.10] X-CanIt-Incident-Id: 031UDv5PF X-CanIt-Geo: ip=128.113.124.17; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 X-Rspamd-Queue-Id: 487kpN4GRxz4FY9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=rpi.edu; spf=pass (mx1.freebsd.org: domain of drosih@rpi.edu designates 128.113.2.230 as permitted sender) smtp.mailfrom=drosih@rpi.edu X-Spamd-Result: default: False [-4.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:128.113.2.225/28]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[230.2.113.128.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[rpi.edu,none]; IP_SCORE(-1.78)[ipnet: 128.113.0.0/16(-4.91), asn: 91(-3.93), country: US(-0.05)]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:91, ipnet:128.113.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:31:09 -0000 On 29 Jan 2020, at 4:26, Gordon Bergling via freebsd-hackers wrote: > Hi, > > I recently stumbled upon the default world readable permissons of > /root and > /etc/sysctl.conf. I think that it would be more secure to reduce the > default > permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > I prepared a differtial for the proposed change: > https://reviews.freebsd.org/D23392 > > What do you think? I wouldn't change /etc/sysctl.conf. If others think it should be changed then I wouldn't object, but I think the permissions are fine as they are. I do think that userid root's home directory does not need to be RX for others, but it seems fine to me if it is RX for group wheel. If you can't trust the users who you have added to group 'wheel', then you've got many other issues to worry about. On my own machines, I usually do change the permissions of /root to be 750, although I see that I forgot to do that on the two new servers that I built just last month! -- Garance Alistair Drosehn = drosih@rpi.edu Lead Developer @rpi and gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@freebsd.org Thu Jan 30 17:15:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D8B7F23F428 for ; Thu, 30 Jan 2020 17:15:02 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 487n6G270Yz4NMC for ; Thu, 30 Jan 2020 17:15:02 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f195.google.com with SMTP id x14so4144307ljd.13 for ; Thu, 30 Jan 2020 09:15:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5xq6WhuxEJ5X/yCZtumbk8OZTBim+kaeJDRLs/ybYnM=; b=laelSpsD/JI80Ze5h/jfvDKvibT7UqGzkyGI+2Nh/fxUAIk2jo9yxPHIRhr+kWCjQk 6KLkZvNSc8lmmgzif0uucIPdXtFkWngK01vkQtxnb5oWgC/YwfTj8ik6W5xqTPzNEq06 3E3vwpj95XwlQm+B3OFPc0j21aqbIdoVraEOWBGIGCF4Bg8zUW33dkDoVGTBJbAyf3ub k/uzaSBJ9GacjwJUn0tMS6i6oc7ojYBrg54StDor89IeNuh5RH7CMisi6gVdQiyz2H9B eN/eUkAMWJkdwLNfr0+ukd0kme6dq81Tp230H0Y+ESkVSpnLjlifcFGlId9fEvt0Uxyb u+fA== X-Gm-Message-State: APjAAAXMlontERKAz3BUP3Ee48GQe3UIEOi3b8qAPhJBHqONbEuuOfNC GIWmkNHp3HiZ1lvhwRUihEN2YIcucnk= X-Google-Smtp-Source: APXvYqyBBwDpziOoHvtzECo7dUkILOSA0pUyYg7bJ60JE41LILKNUV1UQMUetOye0eCqhO9N70Lgug== X-Received: by 2002:a2e:b61a:: with SMTP id r26mr3487154ljn.72.1580404500292; Thu, 30 Jan 2020 09:15:00 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id o6sm3070851lfg.11.2020.01.30.09.14.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jan 2020 09:14:59 -0800 (PST) Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? To: =?UTF-8?Q?Peter_Rap=c4=8dan?= , freebsd-hackers@freebsd.org References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> Date: Thu, 30 Jan 2020 19:14:58 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 487n6G270Yz4NMC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.195 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[195.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.01)[ip: (-0.17), ipnet: 209.85.128.0/17(-3.05), asn: 15169(-1.78), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 17:15:02 -0000 On 30/01/2020 16:42, Peter Rapčan wrote: > Hi, > > Is there a way to tell gptzfsboot NOT to analyze other disks (or specify > which disks to analyze)? (My system is on PATA disk(s) while the data disks > are SATA, hence there is no use to probe the SATA disks to search for a > bootable system). > > I am asking this to get around the following problem (bug?) I encountered > (tried both freeBSD 12.1 and freeNAS [11.2-U4 though 11.3-RC2]): When > booting, I get "gptzfsboot: error 128 lba some_block_number" errors in the > phase when gptzfsboot is probing my data HDDs (on which there is no > bootloader, nor system, the drives can be even empty, with or without a > partition table). The system boots eventually but the boot takes cca N x 7 > minutes, where N is the number of data disks gptzfsboot is trying to analyze > (there are several gptzfsboot: error 128 lba some_block_number lines per disk > and each takes some time to appear). > > Note: installer CD boots the installer system just fine. Also, once the > system is installed, and the system has booted from HDD (this takes ~30 > minutes with multiple gptzfsboot: error 128 lba some_block_number for each > disk) the system works just fine, including the very same data disks that > "produce" the errors. > > Anyway, should this be reported as a bug? > > Any help is greatly appreciated. FWIW, error 128 is likely "Disk timeout (failed to respond)" according to this resource: http://www.bioscentral.com/misc/biosint13.htm That may explain why the boot takes so long. Could it be that something like power-up-in-standby is configured for SATA disks? It's possible that disks are detectable and thus reported by BIOS, but they are not spinning and timing out on reads. Later, FreeBSD kernel knows to send a special command to spin them up. This is just a speculation on my part. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Jan 30 21:19:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 867661FF7A8 for ; Thu, 30 Jan 2020 21:19:54 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 487tXn4Fyjz3CHD for ; Thu, 30 Jan 2020 21:19:53 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00ULJn68070747; Thu, 30 Jan 2020 13:19:49 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00ULJn4Q070746; Thu, 30 Jan 2020 13:19:49 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001302119.00ULJn4Q070746@gndrsh.dnsmgr.net> Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: To: Wojciech Puchar Date: Thu, 30 Jan 2020 13:19:49 -0800 (PST) CC: Ryan Stone , FreeBSD Hackers , Gordon Bergling X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 487tXn4Fyjz3CHD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.42 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.50)[-0.500,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.02)[-0.019,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 21:19:54 -0000 > > > On Wed, 29 Jan 2020, Ryan Stone wrote: > > > On Wed, Jan 29, 2020 at 4:26 AM Gordon Bergling via freebsd-hackers > > wrote: > >> > >> Hi, > >> > >> I recently stumbled upon the default world readable permissons of /root and > >> /etc/sysctl.conf. I think that it would be more secure to reduce the default > >> permission for /root to 0700 and to 0600 for /etc/sysctl.conf. > > > > I don't see the point in making this change to sysctl.conf. sysctls > > are readable by any user. Hiding the contents of sysctl.conf does not > > prevent unprivileged users from seeing what values have been changed > > from the defaults; it merely makes it more tedious. > true. but /root should be root only readable Based on what? What security does this provide to what part of the system? Why should it not also be group wheel readable? Why should a member of wheel have to su to ls /root? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Jan 31 08:10:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B095237B5A for ; Fri, 31 Jan 2020 08:10:54 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4888zx1ykhz4GCs for ; Fri, 31 Jan 2020 08:10:52 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id 00V8Akdb059486 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Jan 2020 09:10:47 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1580458247; bh=ojTuzh1TtTZoVQOIhSVZHjZw74sKR6Mpv8+EI7k2NpE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=quwhyLbAlXCJ0mzTQ7vttcyf/Wg5RCDe6BOoQILlVU2jVKgmJqjdLQgWJ4jdpQ75D 0IdnDYm074meOv1pzrZHcPhzVp1fzPS3xebFvtUjxtu7eLuD74M0UJUwLje9KQuOmz dcNhFVtr2bFRYwZuKTifmbGdXCtVqpzI3uXg6nn0= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id 00V8AkDn059483; Fri, 31 Jan 2020 09:10:46 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 31 Jan 2020 09:10:46 +0100 (CET) From: Wojciech Puchar To: "Rodney W. Grimes" cc: Wojciech Puchar , FreeBSD Hackers , Gordon Bergling , Ryan Stone Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: <202001302119.00ULJn4Q070746@gndrsh.dnsmgr.net> Message-ID: References: <202001302119.00ULJn4Q070746@gndrsh.dnsmgr.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4888zx1ykhz4GCs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=puchar.net header.s=default header.b=quwhyLbA; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.59)[ip: (-6.84), ipnet: 194.1.144.0/24(-3.42), asn: 43476(-2.73), country: PL(0.07)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 08:10:54 -0000 >>> I don't see the point in making this change to sysctl.conf. sysctls >>> are readable by any user. Hiding the contents of sysctl.conf does not >>> prevent unprivileged users from seeing what values have been changed >>> from the defaults; it merely makes it more tedious. >> true. but /root should be root only readable > > Based on what? What security does this provide to what part of the system? based on common sense From owner-freebsd-hackers@freebsd.org Fri Jan 31 10:25:38 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9016923B520 for ; Fri, 31 Jan 2020 10:25:38 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488CzP4sn5z4PsG for ; Fri, 31 Jan 2020 10:25:37 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00VAPZ3s072996; Fri, 31 Jan 2020 02:25:35 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00VAPZts072995; Fri, 31 Jan 2020 02:25:35 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: To: Wojciech Puchar Date: Fri, 31 Jan 2020 02:25:35 -0800 (PST) CC: "Rodney W. Grimes" , FreeBSD Hackers , Gordon Bergling , Ryan Stone X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 488CzP4sn5z4PsG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.232,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.05)[0.045,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 10:25:38 -0000 > >>> I don't see the point in making this change to sysctl.conf. sysctls > >>> are readable by any user. Hiding the contents of sysctl.conf does not > >>> prevent unprivileged users from seeing what values have been changed > >>> from the defaults; it merely makes it more tedious. > >> true. but /root should be root only readable > > > > Based on what? What security does this provide to what part of the system? > based on common sense Who's common sense, as mine and some others say this is an unneeded change with no technical merit. You have provided no technical reasons for your requested change, yet others have presented technical reasons to not make it, so to try and base a support position on "common sense" is kinda moot. We actually discussed this at dinner tonight and no one could come up with a good reason to lock /root down in such a manner unless someone was storing stuff in /root that should probably not really be stored there. Ie, there is a bigger problem than chmod 750 /root is going to fix. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Jan 31 16:13:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2CFAC24408F for ; Fri, 31 Jan 2020 16:13:57 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [46.251.251.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488MjJ10jCz3L4P for ; Fri, 31 Jan 2020 16:13:55 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from e.0x20.net (mail.0x20.net [46.251.251.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3096 bits) server-digest SHA256) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 079D6CA9EF; Fri, 31 Jan 2020 17:13:48 +0100 (CET) Received: (from lars@localhost) by e.0x20.net (8.15.2/8.15.2/Submit) id 00VGDlYP029479; Fri, 31 Jan 2020 17:13:47 +0100 (CET) (envelope-from lars) Date: Fri, 31 Jan 2020 17:13:47 +0100 From: Lars Engels To: "Rodney W. Grimes" Cc: Wojciech Puchar , FreeBSD Hackers , Gordon Bergling , Ryan Stone Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200131161347.GA33086@e.0x20.net> References: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> X-Editor: VIM - Vi IMproved 8.0 User-Agent: Mutt/1.13.2 (2019-12-18) X-Rspamd-Queue-Id: 488MjJ10jCz3L4P X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of lars@e.0x20.net has no SPF policy when checking 46.251.251.56) smtp.mailfrom=lars@e.0x20.net X-Spamd-Result: default: False [1.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.723,0]; FROM_HAS_DN(0.00)[]; IP_SCORE(-0.07)[ip: (-1.17), ipnet: 46.251.251.0/24(-0.58), asn: 31400(1.44), country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.80)[0.801,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[lme@freebsd.org,lars@e.0x20.net]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31400, ipnet:46.251.251.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[lme@freebsd.org,lars@e.0x20.net]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 16:13:57 -0000 On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote: > > >>> I don't see the point in making this change to sysctl.conf. sysctls > > >>> are readable by any user. Hiding the contents of sysctl.conf does not > > >>> prevent unprivileged users from seeing what values have been changed > > >>> from the defaults; it merely makes it more tedious. > > >> true. but /root should be root only readable > > > > > > Based on what? What security does this provide to what part of the system? > > based on common sense > > Who's common sense, as mine and some others say this is an unneeded > change with no technical merit. > > You have provided no technical reasons for your requested change, > yet others have presented technical reasons to not make it, > so to try and base a support position on "common sense" is kinda moot. > > We actually discussed this at dinner tonight and no one could come up > with a good reason to lock /root down in such a manner unless someone > was storing stuff in /root that should probably not really be stored > there. Ie, there is a bigger problem than chmod 750 /root is going to > fix. /root can store config files and shell history with confidential information. From owner-freebsd-hackers@freebsd.org Fri Jan 31 16:58:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF1FD24518A for ; Fri, 31 Jan 2020 16:58:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488Nj249P2z3P2R for ; Fri, 31 Jan 2020 16:58:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ixZcs-000HNL-FG for freebsd-hackers@freebsd.org; Fri, 31 Jan 2020 19:58:38 +0300 Date: Fri, 31 Jan 2020 19:58:38 +0300 From: Slawa Olhovchenkov To: freebsd-hackers@freebsd.org Subject: vm.pmap.pti=0 performance regression Message-ID: <20200131165838.GO38096@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 488Nj249P2z3P2R X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.477,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.31)[-0.311,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.41), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 16:58:47 -0000 I am try to do different benchmark for my application (NETMAP based packet filtering) and see strange behavior: vm.pmap.pti=0 machdep.hyperthreading_allowed=0 caused performance drop about 20% on network thread. In case of vm.pmap.pti=1 machdep.hyperthreading_allowed=0 or vm.pmap.pti=1 SMT=off in bios or vm.pmap.pti=0 SMT=off in bios performance about same and high about 20%. How does that work? From owner-freebsd-hackers@freebsd.org Fri Jan 31 17:30:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E4C7245E60 for ; Fri, 31 Jan 2020 17:30:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 488PPv3hbxz3Qwq; Fri, 31 Jan 2020 17:30:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 00VHUS7K098785 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 17:30:29 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lme@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 00VHUMqf006349 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Feb 2020 00:30:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: More secure permissions for /root and /etc/sysctl.conf To: Lars Engels , "Rodney W. Grimes" References: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> <20200131161347.GA33086@e.0x20.net> Cc: FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar From: Eugene Grosbein Message-ID: <2714b917-37cf-6f0e-102f-5e8b91479c7a@grosbein.net> Date: Sat, 1 Feb 2020 00:30:10 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200131161347.GA33086@e.0x20.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 488PPv3hbxz3Qwq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.81)[ip: (-4.97), ipnet: 2a01:4f8::/29(-2.53), asn: 24940(-1.55), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 17:30:44 -0000 31.01.2020 23:13, Lars Engels wrote: > /root can store config files and shell history with confidential > information. If your shell keeps history file readable for group or others, you should not use such shell. If root or any other user creates files with confidential information, this person should use corresponding umask in its profile or login class. You know, not being able to read a file may be a problem equal to able read another one. From owner-freebsd-hackers@freebsd.org Fri Jan 31 17:39:42 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 57DEF24624C for ; Fri, 31 Jan 2020 17:39:42 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488PcG09d5z3wsh for ; Fri, 31 Jan 2020 17:39:41 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 254032AC8F for ; Fri, 31 Jan 2020 17:39:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 254032AC8F Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? To: freebsd-hackers@freebsd.org References: From: Allan Jude Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> Date: Fri, 31 Jan 2020 12:39:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RrsvURNOlSpCXzsfFTDsxJYMg0BU6LbkN" X-Rspamd-Queue-Id: 488PcG09d5z3wsh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.75 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.77)[-0.768,0]; NEURAL_HAM_LONG(-0.98)[-0.985,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 17:39:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RrsvURNOlSpCXzsfFTDsxJYMg0BU6LbkN Content-Type: multipart/mixed; boundary="9NtOgVpiPkRUp7uR7PWvhnJ2wO3XgNAmK"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? References: In-Reply-To: --9NtOgVpiPkRUp7uR7PWvhnJ2wO3XgNAmK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-01-30 10:09, Peter Rap=C4=8Dan wrote: > Thanks for your reply! >=20 > I believe it is some kind of bug (maybe related to to https://forums.fr= eebsd.org/threads/gptzfsboot-error-128-after-adding-new-disks.65677/ but = the solution provided there makes no difference in my case). >=20 > The funny thing is that the same system with the same type of disks wor= ked before (with 3 data HDDS and freeNAS [11.2-Ux]) there were no gptzfsb= oot errors and the boot time was fast. After I added a 4th data drive and= upgraded the system (freeNAS) to new version, only then I started gettin= g the "gptzfsboot: error 128 lba some_block_number=E2=80=9D errors. Howev= er I was not able revert to the state without the errors, altough I tried= the original version of freeNAS, with 3, 2, or 1 data HDD(s), I tried wi= ping the HDDS, removing the partition table, creating a new one, etc=E2=80= =A6. I even tried installing freeBSD instead of freeNAS :-). >=20 > I am new to freeBSD=E2=80=A6 could you perhaps give me some advice how = to troubleshoot this error? >=20 > Best, > Peter >=20 >=20 Is the 'some_block_number' at or past the end of the disk? Multiply the number by 512 and compare it to the size of the disk. --=20 Allan Jude --9NtOgVpiPkRUp7uR7PWvhnJ2wO3XgNAmK-- --RrsvURNOlSpCXzsfFTDsxJYMg0BU6LbkN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJeNGZWAAoJEBmVNT4SmAt+OUgP/2ZCMCP2OoPIyukflWJG8R92 dER6za2+rLWBulPL4UCLqk1VZtgMwUsmcKbsFjY5IfZd2zxaxoHK1HaHGr4fNyOZ lv+FvWbpw939aVPMKe9Hc8apjhHGJia0Xt3XHyVLbF+ybvOmkdMSa2Y2R71vkaZR VcGVi+MgrVIoUYrutl3OBMLzHYbXRVECw6mlC6fMA5RWRSaKysZMkebcTJhbOImh d8cJYU9X5Vc5ZuHW0qIXSKFb2KCfAWcxtXkr0nL48o0hFTLkc+kDbDbfj9KjJ9QQ m/QYMSr8CX3QnzilZdvALYTJTRb3Cs5CDWzymYYjy5wH+fW2LbK+EgD7esBbmQhk m1W+JESHdsylOq0bKrEcRFNoS+2vDjmEUgB2ytb+DM3s48VWKJPlsCNaU3l1qhbh kiRqilS1RfzHCaAiTBC7DNBEv6aslTxJsRGZ4kUphA8bpmFvzdTZlj3Tgj/MKFVP Bha/nIzWVOPVVKwUjEblUCim57IAPGM1Ll7bLRHq6fvpsnRpFjUAyPkFSJMyL/El +Gw38nnw7nPduPd8ZlbVDDVJGz99AxIfDlg+1fQhz/gdIfOAoQ+8OdibVHHNfo6V rCw7y3vMZmMBOVvlGYOAhTJvpZ0aVgO+EReSFaRYwDFtBlKFfpMc/APXeMy4sZJ/ /6wzR7lFuMF+644jeE0E =wEKe -----END PGP SIGNATURE----- --RrsvURNOlSpCXzsfFTDsxJYMg0BU6LbkN-- From owner-freebsd-hackers@freebsd.org Fri Jan 31 18:17:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1930B1E8565 for ; Fri, 31 Jan 2020 18:17:10 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488QRS6Jmzz43FJ; Fri, 31 Jan 2020 18:17:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 94E1716059; Fri, 31 Jan 2020 19:17:01 +0100 (CET) Date: Fri, 31 Jan 2020 19:17:00 +0100 From: Steffen Nurpmeso To: Lars Engels Cc: "Rodney W. Grimes" , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar Subject: Re: More secure permissions for /root and /etc/sysctl.conf Message-ID: <20200131181700.Sn-C1%steffen@sdaoden.eu> In-Reply-To: <20200131161347.GA33086@e.0x20.net> References: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> <20200131161347.GA33086@e.0x20.net> Mail-Followup-To: Lars Engels , "Rodney W. Grimes" , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar User-Agent: s-nail v14.9.16 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 488QRS6Jmzz43FJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [0.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.876,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.18)[0.179,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.132.0/24, country:DE]; IP_SCORE(0.28)[asn: 15987(1.43), country: DE(-0.02)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:17:10 -0000 Lars Engels wrote in <20200131161347.GA33086@e.0x20.net>: |On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote: |>>>>> I don't see the point in making this change to sysctl.conf. sysctls |>>>>> are readable by any user. Hiding the contents of sysctl.conf \ |>>>>> does not |>>>>> prevent unprivileged users from seeing what values have been changed |>>>>> from the defaults; it merely makes it more tedious. |>>>> true. but /root should be root only readable |>>> |>>> Based on what? What security does this provide to what part of \ |>>> the system? |>> based on common sense |> |> Who's common sense, as mine and some others say this is an unneeded |> change with no technical merit. |> |> You have provided no technical reasons for your requested change, |> yet others have presented technical reasons to not make it, |> so to try and base a support position on "common sense" is kinda moot. |> |> We actually discussed this at dinner tonight and no one could come up |> with a good reason to lock /root down in such a manner unless someone |> was storing stuff in /root that should probably not really be stored |> there. Ie, there is a bigger problem than chmod 750 /root is going to |> fix. | |/root can store config files and shell history with confidential |information. Absolutely. My own /root is in fact shared in between many systems, and many scripts from /etc/ reach into /root/$HOSTNAME/, with some generics in /root/. Practically all of that is Linux though. But it is very nice, since i can share very, very much, and even the hostname= comes from kernel command line parameter, and multiplexes to entirely different setups. efibootmgr is cool, by the way. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Fri Jan 31 21:47:01 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 145C81EDF4A for ; Fri, 31 Jan 2020 21:47:01 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488W5b6VrJz4Ggs; Fri, 31 Jan 2020 21:46:59 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00VLkuIe075353; Fri, 31 Jan 2020 13:46:56 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00VLkuan075352; Fri, 31 Jan 2020 13:46:56 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001312146.00VLkuan075352@gndrsh.dnsmgr.net> Subject: Re: More secure permissions for /root and /etc/sysctl.confg In-Reply-To: <20200131181700.Sn-C1%steffen@sdaoden.eu> To: Steffen Nurpmeso Date: Fri, 31 Jan 2020 13:46:55 -0800 (PST) CC: Lars Engels , FreeBSD Hackers , Gordon Bergling , "Rodney W. Grimes" , Ryan Stone , Wojciech Puchar X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 488W5b6VrJz4Ggs X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.00)[-0.005,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.73)[0.730,0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.02), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 21:47:01 -0000 > Lars Engels wrote in <20200131161347.GA33086@e.0x20.net>: > |On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote: > |>>>>> I don't see the point in making this change to sysctl.conf. sysctls > |>>>>> are readable by any user. Hiding the contents of sysctl.conf \ > |>>>>> does not > |>>>>> prevent unprivileged users from seeing what values have been changed > |>>>>> from the defaults; it merely makes it more tedious. > |>>>> true. but /root should be root only readable > |>>> > |>>> Based on what? What security does this provide to what part of \ > |>>> the system? > |>> based on common sense > |> > |> Who's common sense, as mine and some others say this is an unneeded > |> change with no technical merit. > |> > |> You have provided no technical reasons for your requested change, > |> yet others have presented technical reasons to not make it, > |> so to try and base a support position on "common sense" is kinda moot. > |> > |> We actually discussed this at dinner tonight and no one could come up > |> with a good reason to lock /root down in such a manner unless someone > |> was storing stuff in /root that should probably not really be stored > |> there. Ie, there is a bigger problem than chmod 750 /root is going to > |> fix. > | > |/root can store config files and shell history with confidential > |information. > > Absolutely. My own /root is in fact shared in between many > systems, and many scripts from /etc/ reach into /root/$HOSTNAME/, > with some generics in /root/. Practically all of that is Linux > though. But it is very nice, since i can share very, very much, > and even the hostname= comes from kernel command line parameter, > and multiplexes to entirely different setups. This is one of those cases that I mention of probably doing something outside the norm. Your example of shared /root for me is a bad idea, as if your shared /root should become unavaliable or worse deadlocked your now in a login lockout situation to the very account you probably need to repair the problem. My prefered solution of what you have done is to add a private local /nodedata/$HOSTNAME hierarchy. > > efibootmgr is cool, by the way. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Jan 31 23:07:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3DE911F00EA for ; Fri, 31 Jan 2020 23:07:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488Xsx2Qmxz4M16; Fri, 31 Jan 2020 23:07:01 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 1355316057; Sat, 1 Feb 2020 00:06:58 +0100 (CET) Date: Sat, 01 Feb 2020 00:06:57 +0100 From: Steffen Nurpmeso To: "Rodney W. Grimes" Cc: Lars Engels , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar Subject: Re: More secure permissions for /root and /etc/sysctl.confg Message-ID: <20200131230657.dFSLw%steffen@sdaoden.eu> In-Reply-To: <202001312146.00VLkuan075352@gndrsh.dnsmgr.net> References: <202001312146.00VLkuan075352@gndrsh.dnsmgr.net> Mail-Followup-To: "Rodney W. Grimes" , Lars Engels , FreeBSD Hackers , Gordon Bergling , Ryan Stone , Wojciech Puchar User-Agent: s-nail v14.9.16 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 488Xsx2Qmxz4M16 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [0.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.837,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.58)[0.579,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.132.0/24, country:DE]; IP_SCORE(0.27)[asn: 15987(1.39), country: DE(-0.02)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 23:07:02 -0000 Rodney W. Grimes wrote in <202001312146.00VLkuan075352@gndrsh.dnsmgr.net>: |> Lars Engels wrote in <20200131161347.GA33086@e.0x20.net>: |>|On Fri, Jan 31, 2020 at 02:25:35AM -0800, Rodney W. Grimes wrote: ... |>|>>>> true. but /root should be root only readable ... |>|> We actually discussed this at dinner tonight and no one could come up |>|> with a good reason to lock /root down in such a manner unless someone |>|> was storing stuff in /root that should probably not really be stored |>|> there. Ie, there is a bigger problem than chmod 750 /root is going to |>|> fix. |>| |>|/root can store config files and shell history with confidential |>|information. |> |> Absolutely. My own /root is in fact shared in between many |> systems, and many scripts from /etc/ reach into /root/$HOSTNAME/, |> with some generics in /root/. Practically all of that is Linux ... |This is one of those cases that I mention of probably doing something |outside the norm. Your example of shared /root for me is a bad idea, |as if your shared /root should become unavaliable or worse deadlocked |your now in a login lockout situation to the very account you probably |need to repair the problem. Oh no, sorry for not being clear. /root is not a shared filesystem, it is just that the data under /root is mirrored to a lot of systems. I have no system where /root/ is not on the same physical storage than /etc/. I.e., if a new host enters i adjust some configurations as has to be done, and create a new directory in /root/ -- this is nothing enterprise-alike. It is just that the basic infrastructure is at a central place out of the way of package managers etc. Then adjust as few lines as possible to keep the noise ratio in between original file and packaged file low. (For example the nice rejmerge(1) on CRUX-Linux, or a find(1)+grep(1) on AlpineLinux's .apk-new backup files.) It does not always work, server configuration files for example; for those i try to append to the files which are shipped with the packages. A bit dangerous, sshd for example fixates the first it finds. But works out in practice. I even share infrastructure in between the server and the clients, regarding those scripts, it is just a matter of the existence of a file /etc/.server. Affects mostly /root/net-qos.sh. It is nothing enterprise, like i have said. |My prefered solution of what you have done is to add a private local |/nodedata/$HOSTNAME hierarchy. This would also be an option, of course. I try to stay within my bounds, i like a small /, though i am much less hysterical than i was when i was younger. The FreeBSD 5.3 system i used for over six years for example was super stripped and clean. When i compare with some servers i have ssh access to, sometimes i see temporary files which lay around for years, for example: #?0|unstable9s:sdaoden$ ll /var/tmp/ total 26560 drwxr-xr-x 35 root sys 1024 Jul 25 2011 ../ drwx------ 2 maciej XXX 512 May 26 2013 javaqwIYFm/ ...lots more Ha-ha-ha! No no, better not. Nah, it is just some home-grown private thing, with some per-hostname things, like a backup filelist (to be picked up by /root/backup.sh), cpupower settings (for /root/cpupower.sh), and ditto volume, backlight, rc-hooks (if applicable), kernel configs, filesystem snapshot lists, list of installed packages, etc. For example, on Linux, acpid sends volume adjustment event to /root/acpid.sh, that dispatches to /root/volume.sh, that sources /root/$HOSTNAME/volume, and knows what to do. Likewise with dhcpcd-hook.sh. Like so, a few lines of sh(1)ll variable assignments are usually enough to adapt to a new machine. (This includes backlights with totally different steps and min / max values, the script usually works fine regardless.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Sat Feb 1 11:43:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7168D24C10A for ; Sat, 1 Feb 2020 11:43:27 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488sfk3r4Sz4S2X for ; Sat, 1 Feb 2020 11:43:26 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id t2so11800822wrr.1 for ; Sat, 01 Feb 2020 03:43:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N5WkdDSXP4vnhX6Mj/4Dw/xwCg1TjKmkh93rBbAJGdQ=; b=D2vvNkLsKX+fH3gT9fgxRb4YqiL+ZvhMu6pxeIbFw74ng8DSHRc1HoXeSvihZ4LY8o FR447mY32SlHaRun31kKgv5dcWCF6qFHMReF7LnG/eak7VBMoEaVyDUd5HwPRyWLHOph sgLrl6L5njHf9B8bABMs+J3K0NrfS2SbmEEhVBwLlkTauSYred2F6BUqSLckrVLjwc4F qf5Drae0vJmEfGx8owG2tkn1G7xIivKAFCbMJw7vEla2R9uvpNRRAk1tbaFyZ9DT+/70 RBgzgTkcsGtmRQgQxRxUn/9gyknFf0n/10itnidBXJy4Tvlw6dDpnZ6EEy+JVIZiEdA5 uu4Q== X-Gm-Message-State: APjAAAXGHOVZllJJp8DsVMPoepJMlVPbyknzQdUB9chrjJLtk2GDBLcX hIRwYwXsPZYSCYgJZ/8/asE= X-Google-Smtp-Source: APXvYqwuwD86zgzeZxG24D+Qact3a4RxBXTo7GxCrZJ4hB/DSJm6a/tMXY1Ifssapmx8E9Rlt5RkUw== X-Received: by 2002:adf:e906:: with SMTP id f6mr4262184wrm.258.1580557405008; Sat, 01 Feb 2020 03:43:25 -0800 (PST) Received: from [10.0.1.111] (p4FD3AEF0.dip0.t-ipconnect.de. [79.211.174.240]) by smtp.gmail.com with ESMTPSA id y10sm15808131wrw.68.2020.02.01.03.43.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Feb 2020 03:43:24 -0800 (PST) Sender: Gordon Bergling From: Gordon Bergling Message-Id: <4584E3BE-F412-4902-AFB9-CAE88D660ED1@googlemail.com> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: More secure permissions for /root and /etc/sysctl.conf Date: Sat, 1 Feb 2020 12:43:22 +0100 In-Reply-To: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> Cc: Wojciech Puchar , FreeBSD Hackers , Ryan Stone To: "Rodney W. Grimes" References: <202001311025.00VAPZts072995@gndrsh.dnsmgr.net> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 488sfk3r4Sz4S2X X-Spamd-Bar: / X-Spamd-Result: default: False [-0.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[240.174.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(0.00)[ip: (2.46), ipnet: 2a00:1450::/32(-2.51), asn: 15169(-1.76), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 11:43:27 -0000 Hi Rodney, first, thanks for all the input I received from various people. I = updated the differential and backed out the changes to /etc/sysctl.conf. = I wasn=E2=80=99t aware that sysctl can be invoked from anybody. In the corrected differential [1] I changed the permission for /root to = 0750 in the hope that this could be integrated into FreeBSD. I know that = people shouldn=E2=80=99t store sensitive information in /root but I have = seen it to often in the past. Best regards, Gordon [1] https://reviews.freebsd.org/D23392 = > Am 31.01.2020 um 11:25 schrieb Rodney W. Grimes = : >=20 >>>>> I don't see the point in making this change to sysctl.conf. = sysctls >>>>> are readable by any user. Hiding the contents of sysctl.conf does = not >>>>> prevent unprivileged users from seeing what values have been = changed >>>>> from the defaults; it merely makes it more tedious. >>>> true. but /root should be root only readable >>>=20 >>> Based on what? What security does this provide to what part of the = system? >> based on common sense >=20 > Who's common sense, as mine and some others say this is an unneeded > change with no technical merit. >=20 > You have provided no technical reasons for your requested change, > yet others have presented technical reasons to not make it, > so to try and base a support position on "common sense" is kinda moot. >=20 > We actually discussed this at dinner tonight and no one could come up > with a good reason to lock /root down in such a manner unless someone > was storing stuff in /root that should probably not really be stored > there. Ie, there is a bigger problem than chmod 750 /root is going to > fix. >=20 >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Feb 1 14:26:18 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 075741F81B7 for ; Sat, 1 Feb 2020 14:26:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488xGd1bGcz4bVB for ; Sat, 1 Feb 2020 14:26:17 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ixtiw-0003So-1n for freebsd-hackers@freebsd.org; Sat, 01 Feb 2020 17:26:14 +0300 Date: Sat, 1 Feb 2020 17:26:14 +0300 From: Slawa Olhovchenkov To: freebsd-hackers@freebsd.org Subject: HT detetct Message-ID: <20200201142613.GA8028@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 488xGd1bGcz4bVB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.703,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.26)[-0.257,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.40), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 14:26:18 -0000 No other way to detect HT CPU but from kvm get cpu_apic_ids and from kvm get cpu_present[] and check .cpu_hyperthread? From owner-freebsd-hackers@freebsd.org Sat Feb 1 14:31:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 656F21F83C1 for ; Sat, 1 Feb 2020 14:31:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (107-204-234-170.lightspeed.sntcca.sbcglobal.net [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488xNv2nT1z4bq9 for ; Sat, 1 Feb 2020 14:31:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id 011EVfwO086755; Sat, 1 Feb 2020 14:31:41 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id 011EVfQJ086754; Sat, 1 Feb 2020 06:31:41 -0800 (PST) (envelope-from david) Date: Sat, 1 Feb 2020 06:31:41 -0800 From: David Wolfskill To: Slawa Olhovchenkov Cc: freebsd-hackers@freebsd.org Subject: Re: HT detetct Message-ID: <20200201143141.GL1270@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Slawa Olhovchenkov , freebsd-hackers@freebsd.org References: <20200201142613.GA8028@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="70RKSkhWIM76k30h" Content-Disposition: inline In-Reply-To: <20200201142613.GA8028@zxy.spb.ru> X-Rspamd-Queue-Id: 488xNv2nT1z4bq9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-6.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.53)[ip: (-9.62), ipnet: 107.192.0.0/12(-4.81), asn: 7018(1.82), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 14:31:44 -0000 --70RKSkhWIM76k30h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 01, 2020 at 05:26:14PM +0300, Slawa Olhovchenkov wrote: > No other way to detect HT CPU but from kvm get cpu_apic_ids and from > kvm get cpu_present[] and check .cpu_hyperthread? > .... Not sure what context you have here (driver? shell script? other?). But the output of "sysctl kern.smp.threads_per_core" may be of interest or use in some of those contexts. Peace, david --=20 David H. Wolfskill david@catwhisker.org McConnell's Senators are covering up their whitewash of Trump's malfeasance. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --70RKSkhWIM76k30h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl41i81fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pck3BAgAjuqC9VDp/i38vkVKaUkAAz+fOychsDcgJ07wQiVGXTbalCcUcC1FPC12 duNZUrNjQyuoO/SLp8i0ehWppfyXs1g6QLUoMQGh+EbkuWYbTnQvh0qZ0EpmO/T0 trrvZAoFOz0mcvzWqh8c7XJSgzNzzlTeWPniMU3vKbs8bJtur0i/vq4YciUAbSTW YMKdijz56x2Uoj6plG4XKJCjlvYFhxuPWRvsWI0IvEO+NbLyiBwzKvzDqfAeVubD 8wnddR8z827deTxlNvr+wDOL+IMPRpfigMMu4iM5p5S/q5pKo3RE1o0EGiN0Qb5a QzrjeVZPdBJSxMCp05xS72COH7BNaQ== =oa99 -----END PGP SIGNATURE----- --70RKSkhWIM76k30h-- From owner-freebsd-hackers@freebsd.org Sat Feb 1 15:11:16 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 892B81F9424 for ; Sat, 1 Feb 2020 15:11:16 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488yGW3V6xz4dXP for ; Sat, 1 Feb 2020 15:11:15 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ixuQS-0003fa-O1; Sat, 01 Feb 2020 18:11:12 +0300 Date: Sat, 1 Feb 2020 18:11:12 +0300 From: Slawa Olhovchenkov To: David Wolfskill , freebsd-hackers@freebsd.org Subject: Re: HT detetct Message-ID: <20200201151112.GA8012@zxy.spb.ru> References: <20200201142613.GA8028@zxy.spb.ru> <20200201143141.GL1270@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200201143141.GL1270@albert.catwhisker.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 488yGW3V6xz4dXP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.792,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.07)[-0.073,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.40), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 15:11:16 -0000 On Sat, Feb 01, 2020 at 06:31:41AM -0800, David Wolfskill wrote: > On Sat, Feb 01, 2020 at 05:26:14PM +0300, Slawa Olhovchenkov wrote: > > No other way to detect HT CPU but from kvm get cpu_apic_ids and from > > kvm get cpu_present[] and check .cpu_hyperthread? > > .... > > Not sure what context you have here (driver? shell script? other?). kvm in driver or shell script? c/c++ program. > But the output of "sysctl kern.smp.threads_per_core" may be of interest > or use in some of those contexts. # sysctl kern.smp.threads_per_core sysctl: unknown oid 'kern.smp.threads_per_core' # sysctl kern.smp.threads_per_core kern.smp.threads_per_core: 2 Hmm, like 12.1 and up. OK, thanks! From owner-freebsd-hackers@freebsd.org Sat Feb 1 18:35:51 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4C84E1FF4C8 for ; Sat, 1 Feb 2020 18:35:51 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from smtp.savba.sk (smtp.savba.sk [147.213.1.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4892pZ23HCz3NmP; Sat, 1 Feb 2020 18:35:49 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from [192.168.1.132] (188-167-170-187.static.chello.sk [188.167.170.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fyziprap) by smtp.savba.sk (Postfix) with ESMTPSA id D35F955890; Sat, 1 Feb 2020 19:35:39 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Message-Id: <66180BBD-AB88-4DA0-9F0E-815578AA6925@savba.sk> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Date: Sat, 1 Feb 2020 19:35:38 +0100 In-Reply-To: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> Cc: freebsd-hackers@freebsd.org To: Allan Jude References: <48f04506-b5bf-03b6-2ef8-9d8853961b07@freebsd.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 4892pZ23HCz3NmP X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.rapcan@savba.sk designates 147.213.1.2 as permitted sender) smtp.mailfrom=peter.rapcan@savba.sk X-Spamd-Result: default: False [5.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:147.213.1.0/27]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[savba.sk]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; URI_COUNT_ODD(1.00)[3]; IP_SCORE(1.66)[ipnet: 147.213.0.0/16(4.28), asn: 2607(3.93), country: SK(0.09)]; MV_CASE(0.50)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2607, ipnet:147.213.0.0/16, country:SK]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 18:35:51 -0000 Dear Allan,=20 Thanks for your reply. Assuming the said 512 is in bytes, the = 512*some_block_number are less then the size of the disk. The disk is a = 12TB one and the =E2=80=9Csome_block_numbers" shown are 32, 544, = 2929720352, 2929720864, 1.=20 Additional information: - the same disk(s) worked in the same system without errors previously = (prior version of freeNAS with less disks of the same type) - I have not = been able to revert to the errorless configuration though (I think I = tried all versions of freeNAS I think I could have used and seen = working, with the original number of the harddrives). - when putting the harddrives in a different PC, the gptzfsboot: error = 128 lba some_block_number changed into gptzfsboot: error 32 [if I = remeber the number correctly] lba some_block_number=20 The whole situation seems mysterious to me, given the system was working = without the error messages previously... Best,=20 Peter > On 31 Jan 2020, at 18:39, Allan Jude wrote: >=20 > On 2020-01-30 10:09, Peter Rap=C4=8Dan wrote: >> Thanks for your reply! >>=20 >> I believe it is some kind of bug (maybe related to to = https://forums.freebsd.org/threads/gptzfsboot-error-128-after-adding-new-d= isks.65677/ but the solution provided there makes no difference in my = case). >>=20 >> The funny thing is that the same system with the same type of disks = worked before (with 3 data HDDS and freeNAS [11.2-Ux]) there were no = gptzfsboot errors and the boot time was fast. After I added a 4th data = drive and upgraded the system (freeNAS) to new version, only then I = started getting the "gptzfsboot: error 128 lba some_block_number=E2=80=9D = errors. However I was not able revert to the state without the errors, = altough I tried the original version of freeNAS, with 3, 2, or 1 data = HDD(s), I tried wiping the HDDS, removing the partition table, creating = a new one, etc=E2=80=A6. I even tried installing freeBSD instead of = freeNAS :-). >>=20 >> I am new to freeBSD=E2=80=A6 could you perhaps give me some advice = how to troubleshoot this error? >>=20 >> Best, >> Peter >>=20 >>=20 > Is the 'some_block_number' at or past the end of the disk? >=20 > Multiply the number by 512 and compare it to the size of the disk. >=20 > --=20 > Allan Jude From owner-freebsd-hackers@freebsd.org Sat Feb 1 18:46:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98E071FF836 for ; Sat, 1 Feb 2020 18:46:17 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from smtp.savba.sk (smtp.savba.sk [147.213.1.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48932c5Qsbz3PCt; Sat, 1 Feb 2020 18:46:16 +0000 (UTC) (envelope-from peter.rapcan@savba.sk) Received: from [192.168.1.132] (188-167-170-187.static.chello.sk [188.167.170.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fyziprap) by smtp.savba.sk (Postfix) with ESMTPSA id 1DF7155890; Sat, 1 Feb 2020 19:46:15 +0100 (CET) From: =?utf-8?Q?Peter_Rap=C4=8Dan?= Message-Id: <531110E5-7C45-46ED-8881-728204CFFA17@savba.sk> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How do I tell gptzfsboot NOT to analyze other disks (or specify which disks to analyze)? Date: Sat, 1 Feb 2020 19:46:14 +0100 In-Reply-To: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> Cc: freebsd-hackers@freebsd.org To: Andriy Gapon References: <035de243-caf1-f812-23d2-6efed8e5ee15@FreeBSD.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 48932c5Qsbz3PCt X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.rapcan@savba.sk designates 147.213.1.2 as permitted sender) smtp.mailfrom=peter.rapcan@savba.sk X-Spamd-Result: default: False [4.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:147.213.1.0/27:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[savba.sk]; NEURAL_SPAM_MEDIUM(0.98)[0.975,0]; SUBJECT_ENDS_QUESTION(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.998,0]; IP_SCORE(1.64)[ipnet: 147.213.0.0/16(4.18), asn: 2607(3.93), country: SK(0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:2607, ipnet:147.213.0.0/16, country:SK]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 18:46:17 -0000 Dear Andryi, Thank you for your input. However: - when putting the harddrives in a different PC, the gptzfsboot: error = 128 lba some_block_number changed into gptzfsboot: error 32 [if I = remeber the number correctly] lba some_block_number - the same disk(s) worked in the same system without errors previously = (prior version of freeNAS with less disks of the same type) - I have not = been able to revert to the errorless configuration though (I think I = tried all versions of freeNAS I think I could have used and seen = working, with the original number of the harddrives). So I am reluctant believing the disk timeout would be the cause=E2=80=A6 = Although the disks are kind of large [HGST HUH721212ALN600, 12TB] and = the system is rather old (IBM x3200), and yes, the disk gave a problem = ty my oldish MacPRO (macOS could see the disk only on fresh start but = not on restart).... nevertheless I have specifically checked the disks = worked OK in the IBM machine before ordering (more of) them and they did = (initially). There is no power-up-in-standby option/toggle in the BIOS :-( Best,=20 Peter > On 30 Jan 2020, at 18:14, Andriy Gapon wrote: >=20 > On 30/01/2020 16:42, Peter Rap=C4=8Dan wrote: >> Hi, >>=20 >> Is there a way to tell gptzfsboot NOT to analyze other disks (or = specify >> which disks to analyze)? (My system is on PATA disk(s) while the data = disks >> are SATA, hence there is no use to probe the SATA disks to search for = a >> bootable system). >>=20 >> I am asking this to get around the following problem (bug?) I = encountered >> (tried both freeBSD 12.1 and freeNAS [11.2-U4 though 11.3-RC2]): When >> booting, I get "gptzfsboot: error 128 lba some_block_number" errors = in the >> phase when gptzfsboot is probing my data HDDs (on which there is no >> bootloader, nor system, the drives can be even empty, with or without = a >> partition table). The system boots eventually but the boot takes cca = N x 7 >> minutes, where N is the number of data disks gptzfsboot is trying to = analyze >> (there are several gptzfsboot: error 128 lba some_block_number lines = per disk >> and each takes some time to appear). >>=20 >> Note: installer CD boots the installer system just fine. Also, once = the >> system is installed, and the system has booted from HDD (this takes = ~30 >> minutes with multiple gptzfsboot: error 128 lba some_block_number = for each >> disk) the system works just fine, including the very same data disks = that >> "produce" the errors. >>=20 >> Anyway, should this be reported as a bug? >>=20 >> Any help is greatly appreciated. >=20 >=20 > FWIW, error 128 is likely "Disk timeout (failed to respond)" according = to this > resource: http://www.bioscentral.com/misc/biosint13.htm = > That may explain why the boot takes so long. > Could it be that something like power-up-in-standby is configured for = SATA disks? > It's possible that disks are detectable and thus reported by BIOS, but = they are > not spinning and timing out on reads. > Later, FreeBSD kernel knows to send a special command to spin them up. > This is just a speculation on my part. >=20 >=20 > --=20 > Andriy Gapon From owner-freebsd-hackers@freebsd.org Sat Feb 1 19:05:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF2382281CF for ; Sat, 1 Feb 2020 19:05:03 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4893SH06lHz3QDf for ; Sat, 1 Feb 2020 19:05:02 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 011J4rKR079500; Sat, 1 Feb 2020 11:04:53 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 011J4rBB079499; Sat, 1 Feb 2020 11:04:53 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202002011904.011J4rBB079499@gndrsh.dnsmgr.net> Subject: Re: More secure permissions for /root and /etc/sysctl.conf In-Reply-To: <4584E3BE-F412-4902-AFB9-CAE88D660ED1@googlemail.com> To: Gordon Bergling Date: Sat, 1 Feb 2020 11:04:53 -0800 (PST) CC: "Rodney W. Grimes" , Wojciech Puchar , FreeBSD Hackers , Ryan Stone X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4893SH06lHz3QDf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.69)[-0.687,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.39)[0.390,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[googlemail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.03), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 19:05:04 -0000 > Hi Rodney, > > first, thanks for all the input I received from various people. I updated the differential and backed out the changes to /etc/sysctl.conf. I wasn?t aware that sysctl can be invoked from anybody. > > In the corrected differential [1] I changed the permission for /root to 0750 in the hope that this could be integrated into FreeBSD. I know that people shouldn?t store sensitive information in /root but I have seen it to often in the past. I still can not support that as a change: a) It has been 755 for 26 years on FreeBSD and also as long as I can remeber (aka v4 research). Changing it would be a POLA violation. b) No known security flaw has been shown other than user error. c) The default for home directories in all the BSD's I looked at are 755. d) All distributions I looked at ship /root as 755. This would be FreeBSD as the odd man out. e) This still appears to be an attempt to impose ones own preferences as defaults upon the community. Defaults are resonable, but not necessarily correct for everyone. > Best regards, > > Gordon > > [1] https://reviews.freebsd.org/D23392 > > > Am 31.01.2020 um 11:25 schrieb Rodney W. Grimes : > > > >>>>> I don't see the point in making this change to sysctl.conf. sysctls > >>>>> are readable by any user. Hiding the contents of sysctl.conf does not > >>>>> prevent unprivileged users from seeing what values have been changed > >>>>> from the defaults; it merely makes it more tedious. > >>>> true. but /root should be root only readable > >>> > >>> Based on what? What security does this provide to what part of the system? > >> based on common sense > > > > Who's common sense, as mine and some others say this is an unneeded > > change with no technical merit. > > > > You have provided no technical reasons for your requested change, > > yet others have presented technical reasons to not make it, > > so to try and base a support position on "common sense" is kinda moot. > > > > We actually discussed this at dinner tonight and no one could come up > > with a good reason to lock /root down in such a manner unless someone > > was storing stuff in /root that should probably not really be stored > > there. Ie, there is a bigger problem than chmod 750 /root is going to > > fix. > > > > > > -- > > Rod Grimes rgrimes@freebsd.org > -- Rod Grimes rgrimes@freebsd.org