Removing vm86 support?

[Andrew Lutomirski]

Hi-

I'm asking here because Fedora seems to one of few distros that
enables CONFIG_VM86 on 32-bit kernels.

Would anyone object if the upstream kernel (and hence Fedora) removed
vm86 support?  This would break 16-bit real mode programs under
dosemu.  It would have no effect on 16-bit protected mode programs
under dosemu (i.e. anything that works on a 64-bit kernel), on dosbox
(which you should be using instead of dosemu anyway) or on KVM (which
is also a much better option than dosemu).

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Removing vm86 support?

[Andrew Lutomirski]

On Wed, Jul 8, 2015 at 6:48 AM, Adam Jackson  wrote:
> On Tue, 2015-07-07 at 16:20 -0700, Andrew Lutomirski wrote:
>
>> I'm asking here because Fedora seems to one of few distros that
>> enables CONFIG_VM86 on 32-bit kernels.
>>
>> Would anyone object if the upstream kernel (and hence Fedora) removed
>> vm86 support?  This would break 16-bit real mode programs under
>> dosemu.  It would have no effect on 16-bit protected mode programs
>> under dosemu (i.e. anything that works on a 64-bit kernel), on dosbox
>> (which you should be using instead of dosemu anyway) or on KVM (which
>> is also a much better option than dosemu).
>
> We don't even have dosemu packaged.  Haven't since RHL 7.1 power tools,
> if brew is to be believed, certainly never in Fedora.
>

Ah, it's in rpmfusion, not Fedora.

> I have occasionally appreciated the ability to compare vm86 to x86emu
> when debugging vesa failures, but that's rapidly ceasing to be a thing
> I need to care about.  I do wonder why its something that needs to be
> removed entirely instead of locked in a disused filing cabinet in the
> basement, but I'm not going to shed any tears if it goes away.

It may not end up going away.  I want to mark it BROKEN, which means
that basically everyone's config will disable it.  The problem is that
it's buggy and probably full of security holes.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Jul 18, 2015 1:42 AM, "Florian Weimer"  wrote:
>
> Let's assume I want to start a service as an ordinary user, but allow to
> bind it to a privileged port.  The program implementing the service does
> not manipulate capabilities in any way.
>
> I came up with with this system unit for testing purposes:
>
> [Unit]
> Description=Test unit
>
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/getpcaps self
> Capabilities=cap_net_bind_service+ep
> SecureBits=keep-caps
> User=fweimer
> StandardOutput=journal
>
> However, this does not work, the capability set remains empty.  Is there
> a way to achieve what I want?
>
> The algorithm documented in capabilities(7) suggests that retaining
> effective capabilities across an execve system call absolutely requires
> file capabilities (the inheritable part).  The only way to bypass that
> if you perform the execve call with UID 0 (i.e., the literal UID 0, not
> a capability).
>
> This design is really odd because setting file capabilities always
> increases the attack surface (even if it is just the inheritable bits),
> and the only alternative appears to modify the service so that it is
> capability-aware and switches away from UID 0, and grant sufficient
> capabilities so that it can do so.  At that point, you can just skip the
> configuration in the systemd service and do everything capablity-related
> within the program.
>
> What am I missing?

Nothing.  Inheritable capabilities are nearly useless.

The thing you want is called "ambient" capabilities and should be available
in Linux 4.3.

--Andy

>
> --
> Florian Weimer / Red Hat Product Security
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Jul 20, 2015 4:20 AM, "Florian Weimer"  wrote:
>
> On 07/18/2015 03:53 PM, Andrew Lutomirski wrote:
>
> > Nothing.  Inheritable capabilities are nearly useless.
>
> Wow.
>
> The program that sparked this thread is a Go program.  So basically, we
> have these options if we do not want to run with full capabilities:
>
> (a) Run with UID=0 with restricted capabilities, like many systemd
> services already do.  Do not use fscaps (which are not needed because of
> the UID=0 special case).  This is rather pointless because UID=0 does
> not need capabilities to compromise the system.
>
> (b) Make a copy of the file, put it in a directory which only the
> service user can read (or ship it with 750 permissions and the service
> group controlling it), and set fscaps.  The downside is the large binary
> size (it has to be a copy, a link won't work).  And the service user
> could still run the service with command line options that allow
> privilege escalation.
>

If you set inheritable fscaps but not permitted, this should be reasonably
safe.

Alas, you will have to remove fscaps entirely to be compatible with ambient
caps.

--Andy

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Jul 20, 2015 11:05 AM, "Florian Weimer"  wrote:
>
> On 07/20/2015 05:59 PM, Steve Grubb wrote:
>
> > Today, any application that wants to manipulate capabilities needs to be
> > capability aware.
>
> The application does not want to manipulate capabilities.  I do not want
> to run it as full root.  I don't want to add additional SUID/fscaps to
> the file system.
>
> It's somewhat silly to add a privilege escalation hatch to the file
> system in order to run a daemon with *reduced* privileges.

This is exactly why the ambient caps patch is sitting in -mm.  If you want
to read it and email a quick review, that might help it along.  :)

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb  wrote:
> On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
>> On Jul 20, 2015 11:05 AM, "Florian Weimer"  wrote:
>> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
>> > > Today, any application that wants to manipulate capabilities needs to be
>> > > capability aware.
>> >
>> > The application does not want to manipulate capabilities.  I do not want
>> > to run it as full root.  I don't want to add additional SUID/fscaps to
>> > the file system.
>> >
>> > It's somewhat silly to add a privilege escalation hatch to the file
>> > system in order to run a daemon with *reduced* privileges.
>>
>> This is exactly why the ambient caps patch is sitting in -mm.  If you want
>> to read it and email a quick review, that might help it along.  :)
>
> The real problem with capabilities is there is no way to say, I trust this
> child process with this capability, but don't let it get inherited beyond this
> process that I'm about to start.

Why would you want to do that?  That sounds like a use for LD_PRELOAD.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Mon, Jul 20, 2015 at 2:34 PM, Steve Grubb  wrote:
> On Monday, July 20, 2015 12:45:28 PM Andrew Lutomirski wrote:
>> On Mon, Jul 20, 2015 at 12:26 PM, Steve Grubb  wrote:
>> > On Monday, July 20, 2015 11:09:39 AM Andrew Lutomirski wrote:
>> >> On Jul 20, 2015 11:05 AM, "Florian Weimer"  wrote:
>> >> > On 07/20/2015 05:59 PM, Steve Grubb wrote:
>> >> > > Today, any application that wants to manipulate capabilities needs to
>> >> > > be
>> >> > > capability aware.
>> >> >
>> >> > The application does not want to manipulate capabilities.  I do not
>> >> > want
>> >> > to run it as full root.  I don't want to add additional SUID/fscaps to
>> >> > the file system.
>> >> >
>> >> > It's somewhat silly to add a privilege escalation hatch to the file
>> >> > system in order to run a daemon with *reduced* privileges.
>> >>
>> >> This is exactly why the ambient caps patch is sitting in -mm.  If you
>> >> want
>> >> to read it and email a quick review, that might help it along.  :)
>> >
>> > The real problem with capabilities is there is no way to say, I trust this
>> > child process with this capability, but don't let it get inherited beyond
>> > this process that I'm about to start.
>>
>> Why would you want to do that?
>
> Because you know exactly why the program needs a capability and its not known
> to have children.

I assume you mean that it's known not to have children.  That's a
somewhat unusual thing to know about a program.

> Therefore any children must be because of an exploit. The
> way it is, capabilities are inherited and you can't stop it.

Programs that can usefully drop capabilities should do so.  Having the
program's caller specifically rig it so that execve drops capabilities
seems next to useless as a mitigation technique -- an attacker will
simply refrain from using execve in their exploits.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Jul 21, 2015 4:18 AM, "Florian Weimer"  wrote:
>
> On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:
>
> >> (b) Make a copy of the file, put it in a directory which only the
> >> service user can read (or ship it with 750 permissions and the service
> >> group controlling it), and set fscaps.  The downside is the large
binary
> >> size (it has to be a copy, a link won't work).  And the service user
> >> could still run the service with command line options that allow
> >> privilege escalation.
> >>
> >
> > If you set inheritable fscaps but not permitted, this should be
reasonably
> > safe.
>
> Empirically, this causes the capability to end up in the P set, not the
> E set, which means that the application still needs to be capability to
> enable it.  So it really doesn't help that much in the Go case, sadly.
> Although it is fairly close.

Try 2: set the capability in the inheritable set and set the effective
bit.  (The effective fscap is a single bit, not a mask.  You still program
it with "=ei" because the syntax is wrong.)

--Andy

>
> --
> Florian Weimer / Red Hat Product Security
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Wed, Jul 22, 2015 at 1:22 PM, Lennart Poettering
 wrote:
> What's worse is that in kernels before 2.6.24 passing caps across
> exec() actually worked fine. Kernel broke API heavily in this regard
> by introducing fcaps and altering the caps inheritance logic then.

Are you sure?  I don't recall it ever working.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Granting a capability to a service

[Andrew Lutomirski]

On Wed, Jul 22, 2015 at 1:25 PM, Lennart Poettering
 wrote:
> On Mon, 20.07.15 13:20, Florian Weimer (fwei...@redhat.com) wrote:
>
>> (d) Change the Go program to optionally drop capabilities and switch the
>> user.  Do not use fscaps, and keep running it as full root initially.
>> This is the cleanest approach and what other services use, but I don't
>> think Go currently supports switching credentials in all threads in the
>> process.
>
> Note that caps are weird on Linux. AFAIR they actually apply to
> all kinds of tasks, including threads, not just processes. IIRC Go
> does not give you control when exactly it creates threads, no? This
> makes it difficult to drops caps sanely if you want to ensure they are
> dropped in all threads at the same time, and not just in whatever
> thread was the one started first...

The alternative would be worse.  For example, the effective mask would
be nonsense if were shared between threads.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS-UP] Please test kdbus in Rawhide!

[Andrew Lutomirski]

On Thu, Jul 30, 2015 at 11:20 AM, Josh Boyer  wrote:
> On Thu, Jul 30, 2015 at 2:05 PM, Stephen Gallagher  
> wrote:
>> On Thu, 2015-07-30 at 19:57 +0200, Lennart Poettering wrote:
>>> Heya!
>>>
>>> I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully
>>> added it to the Rawhide kernel packages, and our systemd RPMs come
>>> with built-in support, too now. If you are running an up-to-date
>>> Rawhide system adding "kdbus=1" to your kernel command line is hence
>>> everything you need to run kdbus instead of dbus-daemon. (No
>>> additional RPMs need to be installed.) If you do, things should just
>>> work the same way as before, if we did everything right. By adding or
>>> dropping "kdbus=1" to/from the command line you can enable kdbus or
>>> revert back to dbus1 on each individual boot.
>>>
>>> This stuff is opt-in, and we are very keen on getting feedback and
>>> testing for this. The version of kdbus in Rawhide we consider API
>>> stable, there is a complete client side available now in systemd,
>>> with
>>> a client API in sd-bus. Compatibility with good old dbus1 is provided
>>> by the "systemd-bus-proxy" service.
>>>
>>> The folks involved in kdbus development have been running this code
>>> on
>>> their systems for more than half a year now. There were occasional
>>> hiccups, but we fixed everything we ran into, and it works pretty
>>> well
>>> now. Our focus was specifically on providing the best possible
>>> compatibility with dbus1. Now we'd like to increase the testing
>>> audience and added this to Rawhide because of this.
>>>
>>> Further information about kdbus and how to get started you may find
>>> here:
>>>
>>> http://www.freedesktop.org/wiki/Software/systemd/kdbus/
>>>
>>> We'd very thankful for every Fedora developer testing this and
>>> providing bug reports! Any feedback is highly appreciated.
>>>
>>> Also, should you attend our upcoming conference, we might return the
>>> favour by buying you a beer or two:
>>>
>>> https://systemd.events/
>>>
>>> Thank you,
>>>
>>> Lennart
>>
>>
>> For folks not keen to jump headfirst into Rawhide, is it expected that
>> this should work on Fedora 23 or Fedora 22 if one installs only the
>> kernel and systemd packages from Rawhide? That might make people more
>> comfortable trying it out (and get you more feedback), if so.
>
> You'll probably only need the rawhide kernel.  IIRC, the systemd
> package was kdbus ready before the branch was created.

The last time I tried this (maybe a month ago in Rawhide), booting
with kdbus=1 hung very quickly.  I was told that it needed newer
systemd to work, so I'd be a bit surprised if F22 is reliable.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is it time to allow Chromium in Fedora?

[Andrew Lutomirski]

On Tue, Aug 11, 2015 at 12:12 PM, Chris Murphy  wrote:
> On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox  wrote:
>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> Meanwhile, on OS X I was already given notification of Firefox being
> updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
> koji, there are no Bodhi entries for it, so it's not in any repo.
>
> So I don't really buy any of the security arguments of either "no
> bundled libraries" or the FF exception to it. The delay appears to be
> packaging itself. Mozilla produces an OS X and Windows specific
> packages, and they update themselves rather than going through the OS
> update system. This doesn't happen on Linux, where it's expected
> Firefox gets updated by the distro repo and packaging system. Yet I
> see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder
> why that binary doesn't just run unmodified anywhere and I'm waiting
> for 40.0 to show up in Bodhi?

IMO it would be really really neat if Fedora could deterministically
rebuild whatever binary Mozilla distributes and have a binary
identical package.

/me stops daydreaming

I think that, in general, Fedora is too slow about turning a security
update submitted to stable via Bodhi into an actual available update.
For high-profile things like Firefox, we're pretty good about getting
karma, but even that depends on people manually installing an update
that isn't actually available in updates-testing so they can give it
karma.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Firefox addon signing

[Andrew Lutomirski]

On Fri, Aug 28, 2015 at 12:18 AM, Martin Stransky  wrote:
> On 08/27/2015 04:40 PM, Alexander Ploumistos wrote:
>>
>> Aren't the addons that we ship in fedora a bunch of text files zipped
>> in an xpi archive? It is kind of awkward to send them back and forth,
>> but if there are no other binaries, does it go against a particular
>> policy?
>>
>> Or we could decide that we trust Mozilla's code review process and
>> drop packaging addons altogether, as was suggested. At least the users
>> will receive updates faster.
>
>
> Can we ship addons which are already signed by Mozilla? Or does Fedora
> packager modify them somehow?
>

Another thought: could we ask Mozilla for permission to exempt a
specific directory (e.g. /usr/share/distro-firefox-extensions) from
signature requirements for .xpi files that are owned by root?

After all, anyone who can drop root-owned files in there can just as
easily replace the entire firefox binary.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Andrew Lutomirski]

On Thu, Sep 17, 2015 at 11:59 AM, Germano Massullo
 wrote:
>
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix volume
> level was ~ 35%. When I logged into a video conference application, the
> volume suddenly reached the 100%. I was shocked, having the maximum audio
> level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100% audio
> level, but on the other hand, PulseAudio should never allow an application
> to make such sudden changes.

To clarify: did you get blasted by music or by video conference
sounds?  If the music volume got louder, then it sounds like either a
straight-up bug in PulseAudio (and a severe and dangerous one at that)
or a serious bug in your video conference volume in which it adjusts
the volume of streams other than its own.

If you got blasted by video conference sounds, then I'd say it's a
serious design flaw in PulseAudio.  PulseAudio should offer an
easy-to-configure maximum volume (probably A-weighted power, but peak
level works, too, if considerably less well) on a per-output basis
with which to protect your ears.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: 22: nfs = long boot delay

[Andrew Lutomirski]

On Aug 14, 2014 12:11 PM, "J. Bruce Fields"  wrote:
>
> On Tue, Aug 12, 2014 at 12:58:13AM -0400, Felix Miata wrote:
> > Why when nothing is automounting nfs either as client or server does
boot
> > not proceed to completion without a 2+ minute pause while nfs-server
fails
> > to start?
>
> Sounds like a bug.  Is the failure to start expected?

I wonder whether https://bugzilla.redhat.com/show_bug.cgi?id=1129425 is
related.  It's possible for nfs client mounts to start a copy of rpc.statd
that systemd doesn't know about.

--Andy

>
> > Exportfs never (on my installations) needed fsid= in exports
> > before, why the complaint about its absence now, and with output of
> > showmount -e showing no signs of having failed?
>
> fsid=0 shouldn't be required.  Probably file a bug with the details.
>
> --b.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: 22: nfs = long boot delay

[Andrew Lutomirski]

On Thu, Aug 14, 2014 at 2:25 PM, Felix Miata  wrote:
> On 2014-08-14 12:36 (GMT-0700) Andrew Lutomirski composed:
>
>
>> J. Bruce Fields wrote:
>
>
>>> On Tue, Aug 12, 2014 at 12:58:13AM -0400, Felix Miata wrote:
>
>
>>>> Why when nothing is automounting nfs either as client or server does
>>>> boot
>>>> not proceed to completion without a 2+ minute pause while nfs-server
>>>> fails
>>>> to start?
>
>
>>> Sounds like a bug.  Is the failure to start expected?
>
>
> Not expected by me.
>
>
>> I wonder whether https://bugzilla.redhat.com/show_bug.cgi?id=1129425 is
>> related.  It's possible for nfs client mounts to start a copy of rpc.statd
>> that systemd doesn't know about.
>
>
> I can't tell whether that's related or not. The only significant NFS problem
> I can remember before this, once I originally figured out what little I
> needed to figure out about NFS eons ago when setting up a LAN for the first
> time, had to do with rpcbind replacing portmap.

If you wait long enough for boot to finish, and you do:

# ps -A |grep rpc
# systemctl status nfs-lock

you might get a hint.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: 22: nfs = long boot delay

[Andrew Lutomirski]

[resend -- I hate gmail]

On Fri, Aug 15, 2014 at 7:19 AM, Felix Miata  wrote:
> On 2014-08-14 14:33 (GMT-0700) Andrew Lutomirski composed:
>
>> Felix Miata wrote:
>
>>> On 2014-08-14 12:36 (GMT-0700) Andrew Lutomirski composed:
>
>>>> J. Bruce Fields wrote:
>
>>>>> On Tue, Aug 12, 2014 at 12:58:13AM -0400, Felix Miata wrote:
>
>>>>>> Why when nothing is automounting nfs either as client or server does boot
>>>>>> not proceed to completion without a 2+ minute pause while nfs-server 
>>>>>> fails
>>>>>> to start?
>
>>>>> Sounds like a bug.  Is the failure to start expected?
>
>>> Not expected by me.
>
>>>> I wonder whether https://bugzilla.redhat.com/show_bug.cgi?id=1129425 is
>>>> related.  It's possible for nfs client mounts to start a copy of rpc.statd
>>>> that systemd doesn't know about.
>
>>> I can't tell whether that's related or not. The only significant NFS problem
>>> I can remember before this, once I originally figured out what little I
>>> needed to figure out about NFS eons ago when setting up a LAN for the first
>>> time, had to do with rpcbind replacing portmap.
>
> I miswrote, forgetting about other installations where the nfs delay is on 
> trying to mount after boot instead of nfs delay booting:
> https://lists.fedoraproject.org/pipermail/test/2014-May/121461.html
>
>> If you wait long enough for boot to finish, and you do:
>
>> # ps -A |grep rpc
>> # systemctl status nfs-lock
>
>> you might get a hint.
>
> I'm not sure whether I'm seeing any hint(s) or not:
> ## F21 host gx280
> # nfs-utils-1.3.0-5.0.fc21.i686
>

This is not the result I would have expected if that bug caused it.  I
would have expected to see rpc.statd running but nfs-lock in some kind
of not-running or failed state.

--Andy

> ## before manual nfs mountings
>
> # dmesg | tail
> [   40.430796] cfg80211: Calling CRDA to update world regulatory domain
> [   40.497841] EXT4-fs (sda15): mounted filesystem with ordered data mode. 
> Opts: acl
> [   43.811184] tg3 :02:00.0 eth0: Link is up at 1000 Mbps, full duplex
> [   43.811364] tg3 :02:00.0 eth0: Flow control is on for TX and on for RX
> [  109.308166] NFSD: starting 90-second grace period (net c0d4b180)
> [  109.376839] systemd-journald[250]: Received request to flush runtime 
> journal from PID 1
> # ps -A | grep rpc
>   268 ?00:00:00 rpciod
>   426 ?00:00:00 rpc.idmapd
>   455 ?00:00:00 rpc.statd
>   463 ?00:00:00 rpcbind
>   483 ?00:00:00 rpc.mountd
> # systemctl status nfs-lock
> ● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
>Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled)
>Active: active (running) since Fri 2014-08-15 09:42:03 EDT; 9min ago
>   Process: 454 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS 
> (code=exited, status=0/SUCCESS)
>  Main PID: 455 (rpc.statd)
>CGroup: /system.slice/rpc-statd.service
>└─455 /usr/sbin/rpc.statd --no-notify
>
> Aug 15 09:42:02 gx280 rpc.statd[455]: Version 1.3.0 starting
> Aug 15 09:42:02 gx280 rpc.statd[455]: Flags: TI-RPC
> Aug 15 09:42:03 gx280 systemd[1]: Started NFS status monitor for NFSv2/3 
> locking..
>
> ## after manual nfs mountings
>
> # dmesg | tail
> [   43.811184] tg3 :02:00.0 eth0: Link is up at 1000 Mbps, full duplex
> [   43.811364] tg3 :02:00.0 eth0: Flow control is on for TX and on for RX
> [  109.308166] NFSD: starting 90-second grace period (net c0d4b180)
> [  109.376839] systemd-journald[250]: Received request to flush runtime 
> journal from PID 1
> [  596.937403] FS-Cache: Loaded
> [  596.973968] FS-Cache: Netfs 'nfs' registered for caching
> [  596.985813] Key type dns_resolver registered
> [  597.034781] NFS: Registering the id_resolver key type
> [  597.037038] Key type id_resolver registered
> [  597.039149] Key type id_legacy registered
> # ps -A | grep rpc
>   268 ?00:00:00 rpciod
>   426 ?00:00:00 rpc.idmapd
>   455 ?00:00:00 rpc.statd
>   463 ?00:00:00 rpcbind
>   483 ?00:00:00 rpc.mountd
> # systemctl status nfs-lock
> ● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
>Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled)
>Active: active (running) since Fri 2014-08-15 09:42:03 EDT; 12min ago
>   Process: 454 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS 
> (code=exited, status=0/SUCCESS)
>  Main PID: 455 (rpc.statd)
>CGroup: /system.slice/rpc-statd.service
>└─455 /u

Re: /media -> /run/media???

[Andrew Lutomirski]

On Aug 15, 2014 7:21 PM, "Nico Kadel-Garcia"  wrote:
>
> On Fri, Aug 15, 2014 at 9:47 AM, Ondrej Vasik  wrote:
> > On Fri, 2014-08-15 at 08:07 -0400, Nico Kadel-Garcia wrote:
> >> On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt 
wrote:
> >> > On 08/14/2014 12:17 PM, Matthew Miller wrote:
> >> >> On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote:
> >> >>> Actually I'm going to revert the /media -> /run/media change.
> >> >
> >> > The above sentence is unfortunately ambiguous.
> >> >
> >> >>> It is really not solving the issue it was trying to help with and
in
> >> >>> addition it might be fragile in some cases. Sorry for the noise.
> >> >>
> >> >> H... that should probablt be run through the change process...
it needs
> >> >> release notes at least!
> >> >
> >> > No, I'm sure Ondřej only meant that he'd revert the replacement
> >> > of the /media directory with a symlink to /run/media, which was in
Rawhide
> >> > for only two weeks or so.
> >> >
> >> > He does not intend to change the path where removable media get
mounted.
> >> >
> >> > Michal
> >>
> >> Ondrey, I hope that you meant you'd revert the entire change. and put
> >> removeable media mounting back in /media. I've still not seen a single
> >> reason for the move, only a bugzilla about getting it tot work
> >> correctly. Following the more recent File System hierarchy documents
> >> and putting it in the documented /media makes much more sense.
> >
> > I just reverted the "two weeks in rawhide" symlink change
> > already. /media is no longer symlink in Rawhide. Removeable media mount
> > point is not under control of filesystem package (udisks2 mount them
> > to /run/media/$USER/$Volname ).
> > Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set
> > to 1 to have removeable media mounted in /media instead
> > of /run/media/$USER/ .
>
> *sigh*. Then the default should have been to set
> UDISKS_FILESYSTEM_SHARED to 1. Let people who *want* it in the new
> "/run/media/$USER/mountdir" select it. And it's *still* a violation of
> even the most recent filesystem hierarchy standards, which discuss the
> use of "/run" and "/var/run" for pid files, not for removable media.
> Files in /run are supposed to be scrubbed or truncated at boot time!!!
>
> Think I can get any traction getting that default reset at this point?

No, because:

- Security

- Automatically generated names will never reliably match you expectation
in /media no matter what udisks does.

--Andy

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Systemd boot issue

[Andrew Lutomirski]

On Sep 11, 2014 1:51 AM, "P J P"  wrote:
>
>Hello Chris,
>
> > On Wednesday, 10 September 2014 9:15 PM, Chris Murphy wrote:
> > Well I have no idea what's on the screen at the time of the hang. Maybe
a
> > cell phone photo would be useful. Or maybe you should use the debug
kernel which
> > was one of Paul Wouters suggestions. Or you could go out on a limb and
see if
> > the problem is happening with 3.17rc4 non-debug which is
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=575871
> >
> > There are lots of kernels. Unless you really want to do kernel
troubleshooting,
> > you might just pick a kernel that works.
>
>   Yes, I've resorted to 3.15 for now. Will look at 3.16 again later, got
a sosreport yesterday by trying 3.16 on a F20 VM.

Do you have a copy of that oops?  There's currently a big 3.16 stable
backlog, and the crash might be recognizable.

--Andy

>
> I'll post an update asap. Thank you!
> ---
> Regards
>-Prasad
> http://feedmug.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New package Koji / Bodhi oddities?

[Andrew Lutomirski]

Hi-

I have a new package.  I just got this error:

Package: virtme
NVR: virtme-0.0.1-1.fc22
User: pbrobinson
Status: failed
Tag Operation: tagged
Into Tag: f22

virtme-0.0.1-1.fc22 unsuccessfully tagged into f22 by pbrobinson
Operation failed with the error:
: build virtme-0.0.1-1.fc22 already tagged (f22)

The f20 update (https://admin.fedoraproject.org/updates/virtme-0.0.1-1.fc20)
has been stuck in updates-pending for four days.

Are there known issues somewhere in the pipeline?

Thanks,
Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Latest F-21 updates cause non-booting system on some Haswel systems + workaround

[Andrew Lutomirski]

On Fri, Sep 26, 2014 at 11:37 AM, Hans de Goede  wrote:
> Hi All,
>
> Just spend some time debugging this and thought I should share this, see:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
>
> for details, I've filed a bug to track fixing this in Fedora:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1147062
>
> There are 2 ways this problem shows itself:
>
> 1) If using an initrd which has been generated with the troublesome microcode
> update into it, things may already crash during the initrd, e.g. in my case
> some luks volumes would not unlock because of this
>
> 2) When booting an older kernel (and thus an older initrd) things start 
> crashing
> (mostly systemd* processes, grinding everything to a halt) as soon as udev
> from the rootfs loads the microcode update
>
> 2. often will still get you to an emergency shell, at which point one can
> create a /etc/modprobe.conf.d/no_microcode.conf file with:
>
> blacklist microcode
>
> In there to work around the problem, then regenerate the initrds for newer
> kernels, and you should be good to go until bug 1147062 gets fixed properly.

Yeah, sorry, I should have tried to notify the right Fedora people in advance.

This is a nasty issue, and no one knows how to solve it for real yet.
See this long thread:

http://thread.gmane.org/gmane.linux.kernel/1790211

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Latest F-21 updates cause non-booting system on some Haswel systems + workaround

[Andrew Lutomirski]

On Fri, Sep 26, 2014 at 11:58 AM, Josh Boyer  wrote:
> On Fri, Sep 26, 2014 at 2:53 PM, Andrew Lutomirski  wrote:
>> On Fri, Sep 26, 2014 at 11:37 AM, Hans de Goede  wrote:
>>> Hi All,
>>>
>>> Just spend some time debugging this and thought I should share this, see:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
>>>
>>> for details, I've filed a bug to track fixing this in Fedora:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1147062
>>>
>>> There are 2 ways this problem shows itself:
>>>
>>> 1) If using an initrd which has been generated with the troublesome 
>>> microcode
>>> update into it, things may already crash during the initrd, e.g. in my case
>>> some luks volumes would not unlock because of this
>>>
>>> 2) When booting an older kernel (and thus an older initrd) things start 
>>> crashing
>>> (mostly systemd* processes, grinding everything to a halt) as soon as udev
>>> from the rootfs loads the microcode update
>>>
>>> 2. often will still get you to an emergency shell, at which point one can
>>> create a /etc/modprobe.conf.d/no_microcode.conf file with:
>>>
>>> blacklist microcode
>>>
>>> In there to work around the problem, then regenerate the initrds for newer
>>> kernels, and you should be good to go until bug 1147062 gets fixed properly.
>>
>> Yeah, sorry, I should have tried to notify the right Fedora people in 
>> advance.
>
> I knew about it.  This is basically a breakdown in communication
> between the kernel people and the microcode_ctl owner.  it was
> compounded by the fact that I didn't realize our main dracut
> maintainer was on PTO so I didn't fix dracut myself until this
> morning.
>
>> This is a nasty issue, and no one knows how to solve it for real yet.
>> See this long thread:
>>
>> http://thread.gmane.org/gmane.linux.kernel/1790211
>
> Yeah.  FWIW, I just filed an update to have Fedora use early microcode
> by default.  A COPR of this was tested successfully by a few people
> that had the Haswell issue.
>
> https://admin.fedoraproject.org/updates/dracut-038-29.git20140903.fc21,kernel-3.16.3-302.fc21

Everyone will still crash their system once, though, unless
microcode_ctl learns to blacklist this particular update.

Oh, well.

--Andy

>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Latest F-21 updates cause non-booting system on some Haswel systems + workaround

[Andrew Lutomirski]

On Fri, Sep 26, 2014 at 12:16 PM, Josh Boyer  wrote:
> On Fri, Sep 26, 2014 at 3:05 PM, Andrew Lutomirski  wrote:
>> On Fri, Sep 26, 2014 at 11:58 AM, Josh Boyer  
>> wrote:
>>> On Fri, Sep 26, 2014 at 2:53 PM, Andrew Lutomirski  wrote:
>>>> On Fri, Sep 26, 2014 at 11:37 AM, Hans de Goede  
>>>> wrote:
>>>>> Hi All,
>>>>>
>>>>> Just spend some time debugging this and thought I should share this, see:
>>>>>
>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
>>>>>
>>>>> for details, I've filed a bug to track fixing this in Fedora:
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1147062
>>>>>
>>>>> There are 2 ways this problem shows itself:
>>>>>
>>>>> 1) If using an initrd which has been generated with the troublesome 
>>>>> microcode
>>>>> update into it, things may already crash during the initrd, e.g. in my 
>>>>> case
>>>>> some luks volumes would not unlock because of this
>>>>>
>>>>> 2) When booting an older kernel (and thus an older initrd) things start 
>>>>> crashing
>>>>> (mostly systemd* processes, grinding everything to a halt) as soon as udev
>>>>> from the rootfs loads the microcode update
>>>>>
>>>>> 2. often will still get you to an emergency shell, at which point one can
>>>>> create a /etc/modprobe.conf.d/no_microcode.conf file with:
>>>>>
>>>>> blacklist microcode
>>>>>
>>>>> In there to work around the problem, then regenerate the initrds for newer
>>>>> kernels, and you should be good to go until bug 1147062 gets fixed 
>>>>> properly.
>>>>
>>>> Yeah, sorry, I should have tried to notify the right Fedora people in 
>>>> advance.
>>>
>>> I knew about it.  This is basically a breakdown in communication
>>> between the kernel people and the microcode_ctl owner.  it was
>>> compounded by the fact that I didn't realize our main dracut
>>> maintainer was on PTO so I didn't fix dracut myself until this
>>> morning.
>>>
>>>> This is a nasty issue, and no one knows how to solve it for real yet.
>>>> See this long thread:
>>>>
>>>> http://thread.gmane.org/gmane.linux.kernel/1790211
>>>
>>> Yeah.  FWIW, I just filed an update to have Fedora use early microcode
>>> by default.  A COPR of this was tested successfully by a few people
>>> that had the Haswell issue.
>>>
>>> https://admin.fedoraproject.org/updates/dracut-038-29.git20140903.fc21,kernel-3.16.3-302.fc21
>>
>> Everyone will still crash their system once, though, unless
>> microcode_ctl learns to blacklist this particular update.
>
> The microcode_ctl package that added this update was karma'd out.  So
> it shouldn't be in updates-testing any longer, which will help
> mitigate how wide spread it is.
>
> Also "Everyone" here is "everyone with a Haswell CPU that has HLE
> enabled and managed to get microcode_ctl-2.1-8 from updates-testing in
> the window it was available", which fortunately is not anywhere near
> "everyone in Fedora".  Please use care when throwing around
> generalities.

I missed the fact that the microcode_ctl update was karma'd out.

Nonetheless, at some point it, or something like it, may return, and
unless we're careful, it will crash the system.  With the dracut fix,
the system will reboot successfully, so long as the system crashes
*after* the new initramfs gets generated during microcode_ctl
installation.

Or am I missing some reason that this will work better than I think it will?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

[Andrew Lutomirski]

On Sep 28, 2014 12:25 PM, "Reindl Harald"  wrote:
>
>
> Am 28.09.2014 um 21:15 schrieb drago01:
> > On Sun, Sep 28, 2014 at 8:17 PM, Reindl Harald 
wrote:
> >>
> >> Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
> >>> On 09/28/2014 01:24 PM, drago01 wrote:
>  On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell 
wrote:
> > On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
> >> Developers.
> >>
> >> Testers wanted immediately for:
> >>
> >> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
> >>
> >> and
> >>
> >> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
> >
> > For FC21 was missed a case where TSX was being used and had
> > to push one more update -5 to cover this case.
> 
>  Does that update still make sense given that the kernel / dracut
>  update enables early microcode loading?
> >>>
> >>> What about the case where the user runs a custom kernel?
> >>
> >> then he needs to build it right
> >>
> >> don't get me wrong but you can't seriously disable TSX
> >> completly because a *possible* out-of-distribution kernel
> >
> > Well the microcode update *does* disable TSX (so that only applies to
> > new yet to be introduced cpus) ...
>
> that's the point of what i said:
>
> * you buy a new CPU in 2 months
> * the microcode don't disable TSX there

What hypothetical CPU is this?  I don't think Broadwell has TSX, so I think
we're talking about Skylake here.

> * if glibc now is built without TSX support you gain nothing from new
hardware
> * if kernel loads microcode early and you have hardware supporting
>   TSX and glibc also supports it -> fine you hav ethe feature
>
> it would be a big mistake to disable completly TSX forever and
> if not forever how would someone decide when enable it - the only
> sane way is to get microcode applid as early as possible and
> after that use the CPU feautures which are enabled
>
> > but yeah if you build your own kernel you should try to be
> > as close to possible to the distro config
>
> exactly what i said
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Poodlebleed Bug

[Andrew Lutomirski]

On Wed, Oct 15, 2014 at 9:00 AM, Sérgio Basto  wrote:
> this site
> http://poodlebleed.com/
>
> says that my server with F19 is vulnerable
>
> any news about this ?

Poodlebleed?

For Pete's sake.  The attack is called POODLE, and it's much more
likely to be an attack against a client instead of an attack against a
server.

That being said, if you aren't serving a web page that you need IE6 on
XP to connect to, you can turn off SSLv3 to protect your clients.  The
setting varies depending on what server application you're using.

>
> Thanks,
> --
> Sérgio M. B.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedora 21 lets me install packages without root

[Andrew Lutomirski]

On Mon, Oct 20, 2014 at 10:25 AM, drago01  wrote:
> On Mon, Oct 20, 2014 at 7:00 PM, Reindl Harald  wrote:
>>
>> Am 20.10.2014 um 18:10 schrieb Stephen John Smoogen:
>>>
>>> On 20 October 2014 07:45, Matthew Miller >> > wrote:
>>>
>>> On Mon, Oct 20, 2014 at 06:21:54AM -0700, James Patterson wrote:
>>> > I'd like consistent behavior please.
>>>
>>> When possible, that is ideal. But yum doesn't have a built-in
>>> privilege
>>> escalation mechanism to do this.
>>>
>>> > Typing yum install requires a password, so should be the behaviour
>>> for
>>> > running a command that doesn't exist causing a package to be
>>> installed.
>>>
>>> Only signed packages from system repositories can be installed.
>>>
>>>
>>> So if I mistype 'rm' as rn or rb will lrzsz or rn be installed so that
>>> it does the wrong thing next time? Or is this only some commands? And
>>> beyond removing someone from the wheel group what is the way to turn
>>> this off?
>>
>>
>> uninstall anything in context of packagekit and just use yum
>
> No you can configure polkit instead ... see man polkit.

The last couple times I tried to do anything like that, I ended up in
scary undocumented land.

There's polkit, the modern Javascript config (I think), the legacy
pkla compat thing, and the rules that the pkla compat thing reads.  I
think that man polkit is describing the latter.  And actually testing
a rule is a PITA.

This configuration may be powerful, but IMO it's far from user-friendly.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

U2F and a review swap?

[Andrew Lutomirski]

Has Fedora considered supporting U2F for its infrastructure.  IMO it's
*much* nicer than standard Yubikeys.

On a related note, I will gladly swap a review for libu2f-host:

https://bugzilla.redhat.com/show_bug.cgi?id=1155826

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Cron jobs output are sent to the network by default

[Andrew Lutomirski]

On Oct 29, 2014 11:33 AM, "Miloslav Trmač"  wrote:
>
> - Original Message -
> > I created a new bug [1] that explains that ssmtp is sending all cron
> > jobs output to an external SMTP server. I marked it as a security bug,
> > the security tag was removed and it was recommend to make it public,
> > something I can't do. I will resume the problem here, because there are
> > comments that says that it isn't a security bug, I disagree:
> >
> > 1- Fedora 20 shipped with the feature of not running a SMTP server by
> > default, I was fine with it because I don't need to send emails or
> > receive emails locally using it.
> >
> > 2- an update pulled ssmtp
> >
> > Apr 20 19:06:14 Installed: ssmtp-2.64-11.fc20.x86_64
> > Apr 20 19:06:15 Updated: 1:smartmontools-6.2-5.fc20.x86_64
> >
> > 3- ssmtp is configured by default to send emails to a host named mail
> >
> > 4- If a cron jobs runs the email is sent to mail.[your.domain] without
> > you ever configuring that.
>
> This is certainly not a reasonable default configuration for Fedora.
>
> While I think that it is not a reasonable default configuration for ssmtp
at all, I could be persuaded otherwise; but in that case, it should never
be installed by _anything_ that isn’t an explicit user’s choice (i.e. no
dependencies direct or indirect, no comps group presence, and
ideally/overzealously? an automated test that makes installing ssmtp in a
default product configuration a release blocker).

Given that PackageKit can install things with minimal authentication, this
seems fragile.

Why not change cron's default config instead?

--Andy

> Mirek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Requiring all files in /usr to be world-readable?

[Andrew Lutomirski]

I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467

Thoughts?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Requiring all files in /usr to be world-readable?

[Andrew Lutomirski]

On Fri, Oct 31, 2014 at 10:59 AM, Miloslav Trmač  wrote:
> - Original Message -
>> I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
>>
>> Thoughts?
>
> My intuition is that if an application needs _everything_ in /usr to be 
> readable then it is likely broken.  Something being placed in /usr does _not_ 
> imply that it is supposed to be used by everyone.   An administrator can come 
> and change the permissions at any time, and the packaging guideline would not 
> affect anything not included in Fedora-distributed RPMs.  And if we look only 
> at the cases that would be helped by the proposed guideline, i.e. only 
> depending on Fedora RPM-distributed files (but not being particular about 
> what the purpose of kind of file this is), the application would probably be 
> better off just opening and reading the RPMs from repos directly instead of 
> reusing whatever local damage could have been done to the partition.

I'm fine with having various user tools that want to read from /usr
stop working as non-root if the admin changes the permissions.  But I
think they should work by default.

>
> Perhaps there are useful subsets of files in /usr where mandating this would 
> be useful; but all of /usr is seems like an unnecessary overreach.

That's why I think that individual exceptions should be allowed.  I
don't yet know of a case where I would agree that an exception would
be a good idea, but I don't want to rule it out.

>
> (And to the specific examples brought up: No opinion on systemd services; 
> making setuid binaries not world-readable has a _definite_ benefit when 
> prelink is set up, OTOH that is no longer a default.)

I certainly agree with the prelink issue, but I think that that issue
is obsolete.  There's already a guideline stating that suid binaries
MUST be PIE, and the guideline claims (hopefully correctly) that
prelink doesn't work for PIE executables, so there shouldn't be any
prelinked suid binaries in the first place.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Requiring all files in /usr to be world-readable?

[Andrew Lutomirski]

On Tue, Nov 4, 2014 at 8:42 AM, Miloslav Trmač  wrote:
> Hello,
> - Original Message -
>> On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote:
>> > Hello,
>> > - Original Message -
>> > > On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote:
>> > >
>> > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
>> > > >
>> > > > Thoughts?
>> > >
>> > > I very much agree with this, but I'd really prefer if we'd list what
>> > > is allowed rather than just declare what is forbidden.
>> >
>> > What is the use case for such a blanket requirement?  fpc/467 lists
>> > the virt thing I so far disagree with, and other uses cases in there
>> > actually need much less than all of /usr.
>>
>> We are working on allowing stateless system boot up with /usr. For
>> that I really want the ability that any user can copy /usr to some
>> other place without having privileges, and then boot that
>> up.   Replicating a system shouldn't require privileges.
>
> Could you expand on the flow of thought from “stateless system“ to 
> “distribution by replication” and (separately?) “administration/replication 
> by any user”?  I don’t see how that follows.
>

I can only speak for my own perspective on this, which may not match
Lennart's at all:

A major part of the stateless system idea is that /usr should contain
all of the files needed to boot what is effectively a fresh install.
IOW, systemd should be able to boot a fully-functional system that
starts with an empty /etc and /var, OS code in /usr, and a handful of
kernel-provided mounts and symlinks filling out the root directory.

If /usr is world-readable, then an unprivileged user can use /usr to
boot a fully-functional Fedora system in a number of ways.  They can
pipe it into QEMU/KVM using virtfs (what virtme does, although it's
not currently targeting this usecase), they can bind-mount it into an
unprivileged container (I have no idea whether LXC can do this easily
right now, but it's straightforward.  I imagine that someone will add
support to nspawn to do exactly this at some point.  As of the last
time I looked at the nspawn code, it wasn't set up for this yet,
though.)  They can serve it over whatever protocol they like (NFS
using Ganesha, for example) to another physical machine and run it
there.  I'm sure that other people might think of other uses for this.

virtme will give you a fully function Fedora shell right now (no
systemd) in a couple of seconds.  You can try it:

$ sudo dnf install virtme qemu-system-x86 [or whatever the appropriate QEMU is]
$ virtme-run --installed-kernel

If you try to run any of the audit tools inside virtme, you can't,
because virtme can't read them from /usr.  If I wrote the small amount
of code needed, then you could run:

$ virtme-run --installed-kernel --stateless-usr=/usr --graphics

This is likely to have all kinds of problems as a result of the polkit
rules being unreadable, though.

See:

http://0pointer.net/blog/projects/stateless.html

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Porting initramfs-tools to dracut

[Andrew Lutomirski]

On Tue, Nov 4, 2014 at 5:35 PM, Saurabh Kulkarni  wrote:
> Hi there,
>
> So I've been working on a project that requires me to have my own custom
> initrd. The doc I'm following is specialized for ubuntu, so it makes use of
> mkinitramfs to create initrd, and uses initramfs-tools/scripts and
> initramfs-tools/hooks for serving its purpose. I tried using dracut to
> create a ramdisk, but I cannot figure out how should I incorporate
> additional scripts and hooks into the same. I tried extending a dracut
> module (00bash) by adding *inst_hook cmdline 20 "path to the script" * but
> that doesn't seem to help.

How custom?  What are you trying to do?  Are you trying to boot in an
environment that needs hardware-dependent drivers loaded or is the
environment controlled enough that you don't need all that fanciness.

I'm asking because this thing, while not currently intended for
external use, can generate working initramfses very very quickly and
with so little code that you can see what's going on in a minute or
two:

https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/tree/virtme/mkinitramfs.py

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Porting initramfs-tools to dracut

[Andrew Lutomirski]

On Wed, Nov 5, 2014 at 10:08 AM, Saurabh Kulkarni  wrote:
> HI Andy,
>
> Thanks for your response. No I don't need anything fancy while booting up
> other than access to certain scripts/hooks which are added in
> initramfs-tools directory in case of ubuntu. I'll try to see if this python
> code allows me to do something like that. Also, in general, doesn't dracut
> have any provision wherein we can specify such add ons? Strange..

I consider initramfs-tools hooks to be fancy :)  My script is entirely
self-contained, so, if you want an initramfs feature, it goes in the
script.

--Andy

>
> Best,
> Saurabh
>
> On Tue, Nov 4, 2014 at 5:42 PM, Andrew Lutomirski  wrote:
>>
>> On Tue, Nov 4, 2014 at 5:35 PM, Saurabh Kulkarni  wrote:
>> > Hi there,
>> >
>> > So I've been working on a project that requires me to have my own custom
>> > initrd. The doc I'm following is specialized for ubuntu, so it makes use
>> > of
>> > mkinitramfs to create initrd, and uses initramfs-tools/scripts and
>> > initramfs-tools/hooks for serving its purpose. I tried using dracut to
>> > create a ramdisk, but I cannot figure out how should I incorporate
>> > additional scripts and hooks into the same. I tried extending a dracut
>> > module (00bash) by adding *inst_hook cmdline 20 "path to the script" *
>> > but
>> > that doesn't seem to help.
>>
>> How custom?  What are you trying to do?  Are you trying to boot in an
>> environment that needs hardware-dependent drivers loaded or is the
>> environment controlled enough that you don't need all that fanciness.
>>
>> I'm asking because this thing, while not currently intended for
>> external use, can generate working initramfses very very quickly and
>> with so little code that you can see what's going on in a minute or
>> two:
>>
>>
>> https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/tree/virtme/mkinitramfs.py
>>
>> --Andy
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
>
>
> --
> Saurabh R Kulkarni
> Graduate Student, ECE
> Carnegie Mellon University
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: /boot on Btrfs still not supported, main problem is anaconda and grubby

[Andrew Lutomirski]

On Fri, Mar 20, 2015 at 10:58 AM, drago01  wrote:
> On Fri, Mar 20, 2015 at 6:22 PM, Chris Murphy  wrote:
>> On Fri, Mar 20, 2015 at 7:20 AM, Josef Bacik  wrote:
>>> Cool so then we use grubby for these other cases and use the grub2
>>> stuff for the grub2 case which covers the majority of installs and
>>> lets us use btrfs for /boot.  Then as new features are added to grub2
>>> for btrfs we don't have to worry about some other package being
>>> updated, we just automatically get them when we update the package.
>>> I'll take a look at what needs to be done when I get back from
>>> vacation.  Thanks,
>>
>> Using grub2-mkconfig instead of grubby on x86 was suggested and
>> rejected primarily on the basis that grub-mkconfig discards the
>> existing grub.cfg, which can contain user add/modified entries, and
>> generates a completely new one. Ergo, grubby and GRUB upstreams
>> fundamentally disagree on the fairly basic principle of whether the
>> grub.cfg should be modifiable outside of GRUB tools or regenerated
>> from scratch each time a kernel version or boot parameter change
>> happens.
>
> That is not the only issue.
> If grub itself gets updated and you run grub2-mkconfig the generated
> config file might cause issues with the grub that is actually
> installed on disk (we do not reinstall grub on updates).

Somehow Debian and Ubuntu appear to handle this just fine using
update-grub.  It's a much more pleasant experience than grubby IMO.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: /boot on Btrfs still not supported, main problem is anaconda and grubby

[Andrew Lutomirski]

On Fri, Mar 20, 2015 at 12:06 PM, Chris Murphy  wrote:
> On Fri, Mar 20, 2015 at 11:26 AM, Josef Bacik  wrote:
>> Seems like it's easier to just ditch grubby than patch it, if it takes
>> years to merge patches to provide simple functionality that other
>> distro's already have then we just need to drop it and go with some
>> other solution.  Thanks,
>
> Linux has more bootloaders, distro derivatives (made mutually
> incompatible for sport), and configuration file formats than you and I
> both have fingers and toes. I can count Microsoft and Apple total for
> all device categories on one hand.
>

There was this:

http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

It seems to have died.

> Grubby is effectively the marriage counselor for this bootloader
> insane asylum we have on Linux. So I don't actually think it's easier
> to ditch grubby unless there's political will to pick one bootloader.
> One configuration file format. And a handful of supported bootable
> layouts. And also get FESCo a 12 month supply of earplugs to help
> avoid the ensuing ire of users whose favorite nutty layout is no
> longer supported.

Please let's pick a standard (or at least Fedora standard) way to
store boot loader entries.  The current system is awful.  It's extra
awful when you have to reinstall or switch boot loaders for whatever
reason and all your boot entries are only listed in the old config
file.

--Andy

>
>
> --
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

[Andrew Lutomirski]

On Mon, Apr 13, 2015 at 3:09 AM, Jaroslav Skarvada  wrote:
>
>
> - Original Message -
>> On 01.04.2015 10:29, Jaroslav Skarvada wrote:
>> >>> pm-hibernate is obsolete as others already mentioned.
>> >>
>> >> Do the pm-utils maintainers/upstream know this?
>> >>
>> >
>> > Hi,
>> >
>> > I am pm-utils maintainer. I own some other "legacy" packages and
>> > I am retiring them only if there are good reasons for it
>> > (e.g. unfixed security bugs, breakage, etc.), because there may
>> > be still users using such packages / depending on their functionality.
>> >
>> > Regarding pm-utils, most of the functionality is currently handled
>> > by systemd. If there is anybody still using it, I think it shouldn't be
>> > hard to migrate. Also I think this package may be quite confusing
>> > for newcomers. Upstream said it's dead, so there are probably
>> > good reasons to retire. But currently there are the following
>> > packages in rawhide depending on pm-utils:
>> >
>> > cdm
>> > kdebase3
>>
>>
>> Same as with the 'cdm'.
>>
>> http://pkgs.fedoraproject.org/cgit/kdebase3.git/commit/?id=2221c4
>> +
>> kdebase3.spec
>> Patch26: kdebase-3.5.5-suspend.patch
>> %define _with_suspend 1
>> %{?_with_suspend:%patch26 -p1 -b .suspend}
>>
>> ---
>>  kdebase-3.5.5-suspend.patch | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kdebase-3.5.5-suspend.patch b/kdebase-3.5.5-suspend.patch
>> index 0462543..e1a5d0a 100644
>> --- a/kdebase-3.5.5-suspend.patch
>> +++ b/kdebase-3.5.5-suspend.patch
>> @@ -62,8 +62,8 @@
>>  +void KSMShutdownDlg::slotSuspend()
>>  +{
>>  +switch ( suspendType ) {
>> -+   case SUSPEND_TYPE_HIBERNATE: system("/usr/bin/pm-hibernate"); break;
>> -+   case SUSPEND_TYPE_STANDBY: system("/usr/bin/pm-suspend"); break;
>> ++   case SUSPEND_TYPE_HIBERNATE: system("/usr/bin/systemctl hibernate");
>> break;
>> ++   case SUSPEND_TYPE_STANDBY: system("/usr/bin/systemctl suspend");
>> break;
>>  +}
>>  +reject();
>>  +}
>>
>> ...
>>
>> > I will drop pm-utils when resolved
>> >
>> > regards
>> >
>> > Jaroslav
>> >
>>
>> And that's it.
>> - cdm DONE
>> - kdebase3 DONE
>> - wicd DONE
>> - pm-utils DONE
>>
>>
>>
>
> Thanks,
>
> retired in master

Is that good enough?  Should systemd obsolete it, too?  I thought the
whole point of this thread was that pm-utils was actively dangerous
now, so shouldn't we actively remove it from users' systems?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Andrew Lutomirski]

On Thu, Apr 30, 2015 at 5:11 PM, Adam Williamson
 wrote:
> On Thu, 2015-04-30 at 19:45 -0400, Felix Miata wrote:
>> Adam Williamson composed on 2015-04-30 16:37 (UTC-0700):
>>
>> > I'd prefer objective analysis over anecdata. poettering's
>> > contention
>> > is :
>>
>> > i) there is only a problem if you have time-based fsck enabled
>> > ii) this is not the default
>>
>> > your anecdote does not provide enough information to prove or
>> > disprove
>> > his contention.
>>
>> He never mentioned what time-based fsck is that I saw,
>
> "What doesn't work is rtc-in-local in early-boot, that's all. And that
> doesn't matter really, except if you are crazy enough to manually
> enable time-based fsck in ext234, which has been turned off by default
> in fedora since time begain, and even has been turned off upstream
> now, because it's simply a crazy feature." - Lennart, yesterday:
> https://lists.fedoraproject.org/pipermail/devel/2015-April/210282.html

$ sudo tune2fs -l [my ext4 root device]
...
Mount count:  7
Maximum mount count:  21
Last checked: Mon Apr  6 10:42:37 2015
Check interval:   15552000 (6 months)
Next check after: Sat Oct  3 10:42:37 2015
...

This filesystem has survived several Fedora upgrades, but I'm pretty
sure I created it with mke2fs on some Fedora version.  This suggests
that time-based fsck is or was default-enabled at some point.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald  wrote:
>
> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
>>>
>>> "RSB" == Ryan S Brown  writes:
>>
>>
>> RSB> I disagree; for server & cloud deployments it doesn't make sense to
>> RSB> duplicate a DNS server on *every* host, and if you care about
>> RSB> DNSSEC you likely already run a trusted resolver.
>>
>> I disagree generally in the case of server deployments.
>>
>> Having a local caching resolver is pretty much essential, even though we
>> all know it's just a workaround for glibc.
>
>
> no it is not in case of a serious server setup - period

I'm with Jason here.  Glibc's resolver is amazingly buggy, and things
break randomly and unreproducibly when this happens.  A good setup
would have a local resolver and glibc would be configured to cache
nothing whatsoever.  Then, if you need to perform maintenance on the
local DNS cache, you can do it by flushing your local resolver rather
than trying to figure out how you're going to persuade every running
program to tell glibc to flush its cache.

>
>> Basically, if you have properly functioning DNS on multiple local
>> servers but not having anything fancier like heartbeat-based IP handoff
>> or a load balancing appliance or something, and the first resolver in
>> resolv.conf goes offline, your hosts are screwed.  glibc's resolver code
>> is simply horrible.  This is completely exclusive of DNSSEC issues.
>
>
> if your *LAN* nameservers are going offline you need to solve that problem
> and ask you why

I would think that avoiding a single point of failure (your LAN
nameserver) would be a *good* thing.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown  wrote:
> On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote:
>>> "RSB" == Ryan S Brown  writes:
>>
>> RSB> I disagree; for server & cloud deployments it doesn't make sense to
>> RSB> duplicate a DNS server on *every* host, and if you care about
>> RSB> DNSSEC you likely already run a trusted resolver.
>>
>> I disagree generally in the case of server deployments.
>>
>> Having a local caching resolver is pretty much essential, even though we
>> all know it's just a workaround for glibc.
>>
>> Basically, if you have properly functioning DNS on multiple local
>> servers but not having anything fancier like heartbeat-based IP handoff
>> or a load balancing appliance or something, and the first resolver in
>> resolv.conf goes offline, your hosts are screwed.  glibc's resolver code
>> is simply horrible.  This is completely exclusive of DNSSEC issues.
>
> I don't think it's essential for either the server or the cloud product.
> Servers run in a much more reliable network than your average SOHO or
> coffee shop setup, and their behavior with regard to DNS doesn't need a
> local caching resolver. LAN DNS (probably with split horizon for
> DC-internal services) is plenty fast and reliable, there isn't a need to
> run a zillion instances of Unbound.

I agree it's not essential for a server, but it can be quite helpful
to work around glibc bugs.  For example, I've hit
https://sourceware.org/bugzilla/show_bug.cgi?id=17802 several times in
production.  Yes, that's a glibc bug, and glibc should fix it.
Nonetheless, bugs like that wouldn't matter as much if there were a
local resolver.

>
> I don't think so -- when I pull a fresh server image I expect there to
> be very little running on it.
>
> A local DNS resolver would certainly be a surprise to me. Again, this
> comes back to the expectation that a server isn't hopping networks or
> running somewhere un-trusted where there's a high risk of bad actors.

It's not just bad actors.  Sometimes things break or you need to
reconfigure your upstream resolvers.  With a local caching resolver,
this Just Works (tm).  With the status quo, it requires restarting
everything.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams  wrote:
> Once upon a time, Andrew Lutomirski  said:
>> I'm with Jason here.  Glibc's resolver is amazingly buggy, and things
>> break randomly and unreproducibly when this happens.  A good setup
>> would have a local resolver and glibc would be configured to cache
>> nothing whatsoever.  Then, if you need to perform maintenance on the
>> local DNS cache, you can do it by flushing your local resolver rather
>> than trying to figure out how you're going to persuade every running
>> program to tell glibc to flush its cache.
>
> glibc doesn't have a cache, except each process caching the settings in
> /etc/resolv.conf.  That's part of the problem, because there's no way to
> cache "first server in resolv.conf is not responding", so each lookup
> has to figure that out for itself (many timeouts).

Glibc caches *something* that enabled the bug I hit.  I don't know
exactly what it's trying to cache, but it's certainly stateful.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Jun 1, 2015 at 1:42 PM, drago01  wrote:
> On Mon, Jun 1, 2015 at 9:28 PM, Andrew Lutomirski  wrote:
>> On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown  wrote:
>>> On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote:
>>>>>>>>> "RSB" == Ryan S Brown  writes:
>>>>
>>>> RSB> I disagree; for server & cloud deployments it doesn't make sense to
>>>> RSB> duplicate a DNS server on *every* host, and if you care about
>>>> RSB> DNSSEC you likely already run a trusted resolver.
>>>>
>>>> I disagree generally in the case of server deployments.
>>>>
>>>> Having a local caching resolver is pretty much essential, even though we
>>>> all know it's just a workaround for glibc.
>>>>
>>>> Basically, if you have properly functioning DNS on multiple local
>>>> servers but not having anything fancier like heartbeat-based IP handoff
>>>> or a load balancing appliance or something, and the first resolver in
>>>> resolv.conf goes offline, your hosts are screwed.  glibc's resolver code
>>>> is simply horrible.  This is completely exclusive of DNSSEC issues.
>>>
>>> I don't think it's essential for either the server or the cloud product.
>>> Servers run in a much more reliable network than your average SOHO or
>>> coffee shop setup, and their behavior with regard to DNS doesn't need a
>>> local caching resolver. LAN DNS (probably with split horizon for
>>> DC-internal services) is plenty fast and reliable, there isn't a need to
>>> run a zillion instances of Unbound.
>>
>> I agree it's not essential for a server, but it can be quite helpful
>> to work around glibc bugs.  For example, I've hit
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17802 several times in
>> production.  Yes, that's a glibc bug, and glibc should fix it.
>> Nonetheless, bugs like that wouldn't matter as much if there were a
>> local resolver.
>
> That's not how bugs should be dealt with ... if there is a bug it
> should be fixed where it is not duct taped this way.

This is glibc we're talking about, though.  Have you tried to get a
glibc bug fixed?  It's not a pleasant experience.

For example, the bug I reported has a candidate patch.  That patch
isn't applied, and the patch looks like the bug might be a security
issue.  It's been in that state for months.  This is not unusual for
glibc.

Anyway, even on a LAN, the overhead of a network round trip per
cacheable DNS query may be non-negligable for some use cases.  A local
caching resolver fixes that, too.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Tue, Jun 2, 2015 at 2:44 AM, Florian Weimer  wrote:
> On 06/01/2015 10:57 PM, Andrew Lutomirski wrote:
>
>> This is glibc we're talking about, though.  Have you tried to get a
>> glibc bug fixed?  It's not a pleasant experience.
>
> It is possible, but it requires effort.  Admittedly, sometimes that
> effort appears disproportionate to what is being fixed.
>
> In this particularly case, only *very* few people are familiar with
> resolv/, and test coverage for that part is extremely poor.
>
>> For example, the bug I reported has a candidate patch.  That patch
>> isn't applied, and the patch looks like the bug might be a security
>> issue.  It's been in that state for months.  This is not unusual for
>> glibc.
>
> Can you explain why you think it is a security issue?

I don't have any very specific reason, but it's a load from an array
with the entirely wrong index, and the code is inscrutable.  I don't
know whether n is attacker-controlled.

As a mitigating factor, it's a load, so it's probably not so terrible.

Regardless, this seems like a bug wrangling failure.  The fix was
committed AFAICT, but no one updated the bug.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams  wrote:
> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>> > decision needs to then be made by the system. I believe that's been
>> > mostly due to lack of time for the various parties to sit down and
>> > plan and then program this further.
>>
>> We should try to make that happen.
>
> Unfortunately the Proposal doesn't say anything about how this will
> actually work, which is something NetworkManager needs to know.  It also
> fails to address the failure cases where your local DNS doesn't support
> DNSSEC or is otherwise broken here out of no fault of your own.
>
>> > >I see that there's a "hotspot sign on" option if you right click on the
>> > >icon. How does this work with Network Manager and GNOME's captive
>> > >portal detection?
>> > I have never seen those work except for when the backend was down and
>> > I got a stream of false positives. But possibly that is because I've used
>> > dnssec-trigger for years now and it might win the captive portal
>> > detection race. There are some bugs once in a while but overal it works
>> > pretty reliably.
>>
>> I think that's probably it — the race. The hotspot signon thing works
>> for me at coffeeshops. Or it did before I enabled this feature. We'll
>> see now!
>
> So, if you're behind a portal then unbound could potentially fail all
> DNS lookups.  That means that NetworkManager's connectivity detection,
> which relies on retrieving a URL from a known website, will fail because
> the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> detection will also fail.  That kinda sucks.

I think that part of the problem is that there are too many
implementations of captive portal detection and too many
half-thought-out implementations of what do do if a captive portal is
detected.

I think that, on a well-functioning system, if I connect to a wireless
network, something should detect if I'm behind a captive portal.  If
so, I should get a stateless browser that clearly indicates that it's
a captive portal browser, probably lives in a sandbox, and sees the
raw view of the network (no local DNSSEC validation).  We have network
namespaces -- the browser part is doable even in a scenario where we
wouldn't want to expose the incorrect view of DNS or some other aspect
of the network to normal applications.   (Heck, on a configuration
where we want to use a VPN over untrusted wireless, we could avoid
exposing the untrusted wireless network to applications other than
captive portal login at all.)

Please note that the current GNOME captive portal mechanism is
blatantly insecure, and I've already filed a bug report with no
resolution.  I'm not disclosing a subtle 0-day here -- the insecurity
is fairly obvious.  I'll probably post to oss-security soon, but
that's a somewhat separate topic.

Once we determine that there's no captive portal or that we've logged
in to it, we should validate DNSSEC and otherwise behave sensibly.  If
the network is screwed up enough that normal DNSSEC can't get through
the DHCP-provided resolver (which happens -- I've seen ISPs that
tamper with DNS results for www.google.com), then we should tunnel
around it.  IIRC dnssec-triggerd already supports this.

>
> While I'm sure the dnssec-trigger panel applet works great for some
> people, I think the GNOME team would rather have the portal
> functionality in the existing GNOME Shell indicator.  There is nothing
> wrong with having DNSSEC enabled and part of the portal detection
> scheme, but the UI handling portals is clearly a desktop-specific
> decision.

This hasn't worked so well in the past.  Back when NM provided its own
UI, that UI tended to work.  These days I frequently notice the
gnome-shell UI for networking, bluetooth, etc missing features that
are supported by the backend or just straight-up not working.

> So whatever we need to do in NM to enable the workflow that
> desktops need is what we'll end up doing...  Ideally the process goes
> like this when unbound/dnssec-trigger are installed:
>
> 1. NM connects to a new network
> 2. NM updates DNS information

Updates what information to what?  resolv.conf should be more or less invariant.

> 3. NM waits for some signal from unbound/dnssec-trigger about the
> trustability of the DNS server
> 3a. if the DNS server is trusted, NM continues with its connectivity
> check
> 3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
> do we distinguish between "portal" and simply that your local DNS
> doesn't support DNSSEC or is otherwise broken, if we cannot resolve the
> address of the connectivity server?

I smell a turf war, sadly.

I don't think that "local unbound using dnssec-triggerd isn't NM"
should be a show-stopper.  I'd like the see the result work correctly,
and, honestly, if gnome-shell isn't part of the solution, then that's
probably a good thing.  Clearly it should be integrated 

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Fri, Jun 12, 2015 at 10:17 AM, Dan Williams  wrote:
> On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
>> 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
>> a dedicated container and any DNS requests in that container are
>> thrown away with the container once hotspot has been authenticated.
>> This would allow us to never have resolv.conf on the host be
>> different from 127.0.0.1. (currently, it needs to put in the hotspot
>> DNS servers for the hotspot logon, exposing other applications to
>> fake DNS)
>
> I'm not sure a container really needs to be involved as long as the DNS
> resolution can be done without hitting resolv.conf.  That's not hugely
> hard to do I think as long as we can manually resolve the connectivity
> URI address without telling applications about the new DNS servers.
>

If you have automatic VPN connection enabled, then I don't really see
how a captive portal login can be done fully safely without a
container -- the captive portal login should see a route or even
interface that should never be visible to anything else.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Fri, Jun 12, 2015 at 10:33 AM, Dan Williams  wrote:
> On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
>> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams  wrote:
>> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>> >> > decision needs to then be made by the system. I believe that's been
>> >> > mostly due to lack of time for the various parties to sit down and
>> >> > plan and then program this further.
>> >>
>> >> We should try to make that happen.
>> >
>> > Unfortunately the Proposal doesn't say anything about how this will
>> > actually work, which is something NetworkManager needs to know.  It also
>> > fails to address the failure cases where your local DNS doesn't support
>> > DNSSEC or is otherwise broken here out of no fault of your own.
>> >
>> >> > >I see that there's a "hotspot sign on" option if you right click on the
>> >> > >icon. How does this work with Network Manager and GNOME's captive
>> >> > >portal detection?
>> >> > I have never seen those work except for when the backend was down and
>> >> > I got a stream of false positives. But possibly that is because I've 
>> >> > used
>> >> > dnssec-trigger for years now and it might win the captive portal
>> >> > detection race. There are some bugs once in a while but overal it works
>> >> > pretty reliably.
>> >>
>> >> I think that's probably it — the race. The hotspot signon thing works
>> >> for me at coffeeshops. Or it did before I enabled this feature. We'll
>> >> see now!
>> >
>> > So, if you're behind a portal then unbound could potentially fail all
>> > DNS lookups.  That means that NetworkManager's connectivity detection,
>> > which relies on retrieving a URL from a known website, will fail because
>> > the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
>> > detection will also fail.  That kinda sucks.
>>
>> I think that part of the problem is that there are too many
>> implementations of captive portal detection and too many
>> half-thought-out implementations of what do do if a captive portal is
>> detected.
>>
>> I think that, on a well-functioning system, if I connect to a wireless
>> network, something should detect if I'm behind a captive portal.  If
>> so, I should get a stateless browser that clearly indicates that it's
>> a captive portal browser, probably lives in a sandbox, and sees the
>> raw view of the network (no local DNSSEC validation).  We have network
>> namespaces -- the browser part is doable even in a scenario where we
>> wouldn't want to expose the incorrect view of DNS or some other aspect
>> of the network to normal applications.   (Heck, on a configuration
>> where we want to use a VPN over untrusted wireless, we could avoid
>> exposing the untrusted wireless network to applications other than
>> captive portal login at all.)
>>
>> Please note that the current GNOME captive portal mechanism is
>> blatantly insecure, and I've already filed a bug report with no
>> resolution.  I'm not disclosing a subtle 0-day here -- the insecurity
>> is fairly obvious.  I'll probably post to oss-security soon, but
>> that's a somewhat separate topic.
>>
>> Once we determine that there's no captive portal or that we've logged
>> in to it, we should validate DNSSEC and otherwise behave sensibly.  If
>> the network is screwed up enough that normal DNSSEC can't get through
>> the DHCP-provided resolver (which happens -- I've seen ISPs that
>> tamper with DNS results for www.google.com), then we should tunnel
>> around it.  IIRC dnssec-triggerd already supports this.
>
> So it sounds like there are two levels here:
>
> 1) connectivity detection and hotspot login using the network-provided
> DNS servers, which are quite possibly insecure and/or broken
>
> 2) once that is all done, handling DNSSEC issues if the network-provided
> DNS servers are insecure/broken.
>
> Which is fine; I'm mostly concerned with #1 at this point because I
> don't think NetworkManager has much to do with #2 since it already has
> mechanisms to push the network's DNS servers to whatever wants it
> (unbound, etc).

Fair enough.

To me, it seems like the awkward interaction is that we sort of have a
layering vi

Re: F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Fri, Jun 12, 2015 at 3:32 PM, Michael Catanzaro  wrote:
> On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote:
>> It wouldn't really have to be Firefox, but getting the browser chrome
>> right to avoid trivial phishing attacks is critical, and all real
>> browsers already do that fairly well, whereas the simple embedded web
>> views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong.
>
> Hi, it sounds like we have a problem to fix in gnome-shell-portal
> -helper. What specifically are your requirements for the browser
> chrome? I figure as long as the window title is something along the
> lines of "Connect to wireless network" and the hotspot can't change
> that, then we should be good?

Barely.  GNOME seems to do its best to hide window titles, so
something like a URL bar is probably a better bet.  Also, users are
already (hopefully) trained to look for an indication in the URL bar
that something is secure or insecure.

> We could also put a short explanation of
> what is going on in a GtkInfoBar to make it really stand out. I guess
> the goal is to make the chrome distinctive enough that a user stops to
> think "something is not right, don't enter password" when the captive
> portal helper appears and displays google.com.

But that's not even right.  Suppose you have a captive portal that
wants you to log in via your Google account.  It can send you do
https://accounts.google.com, and your browser can verify the
certificate and show you an indication that the connection is secure.
Then you really can safely enter your password.

With the current gnome-shell-portal-helper, there is no chrome at all,
which means that the captive portal gets to show its own chrome, and
it could, for example, make the login window look exactly like
Firefox.  I bet that even the most sophisticated users lose in that
case.

I think the UI should look like a real browser except that it should
clearly indicate that it's a "Log in to wireless network" browser in
addition to showing a standard URL bar.

https://bugzilla.gnome.org/show_bug.cgi?id=749197

>
> FWIW the tech used for GNOME apps that need a web view is WebKitGTK+.

Can that provide real chrome?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)

[Andrew Lutomirski]

On Jun 13, 2015 4:28 AM, "Michael Catanzaro"  wrote:
>
> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > >
> > But that's not even right.  Suppose you have a captive portal that
> > wants you to log in via your Google account.  It can send you do
> > https://accounts.google.com, and your browser can verify the
> > certificate and show you an indication that the connection is secure.
> > Then you really can safely enter your password.
>
> Hmmm, I didn't realize legitimate portals might take you to the public
> Internet.

I think I've seen this in airports and in some hotel chains.

> It'd be nice to not show
> http://www.gnome.org (the test URL we load, expecting to be hijacked)
> if the portal decides not to redirect you to a new URI (not sure how
> common that is), but I think we will have to or we can't fix this

It could be http://generic-network-login.org or something like that.

>
> > I think the UI should look like a real browser except that it should
> > clearly indicate that it's a "Log in to wireless network" browser in
> > addition to showing a standard URL bar.
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=749197
>
> Can you please CC me on that bug? I didn't know GNOME Bugzilla even had
> private bugs. :D

Done.  I don't think I'm the one who made it private.

>
> > > FWIW the tech used for GNOME apps that need a web view is
> > > WebKitGTK+.
> >
> > Can that provide real chrome?
>
> The web view is a GtkWidget: you pack it like any other GtkWidget into
> your hierarchy, and put your own chrome around it. In this case, a URL
> bar would not make any sense since we don't want the user changing the
> URL; we'll probably want to display an unmodifiable URL alongside a
> security indicator.

I guess the reason to keep it read-only is to prevent people from using it
like a real browser.

--Andy

>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)

[Andrew Lutomirski]

On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters  wrote:
> On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
>
>> Is the code on how ChromeOS or Android detects captivity part of the
>> 'public' code? It seems to do a 'good' job in finding many captive
>> portals so might be something to get an idea on how many weird ways
>> things are out there.
>
>
> I think everyone does it similarly. Apple, Google, etc.
>
> You have a web server with a guarantee on no HTTP redirect. You expect
> some specific content, typicall "OK" to be there in the proper mime
> type. (usually text) If you get different text or a redirect or other
> error (eg forbidden) then you assume you're in a captive portal.
>
> Apple (foolishly) used to use something like http://apple.com/hotspot
> on their main site itself, which meant that using a VPN on demand could
> never protect apple.com because the iphone had to leave that domain out
> of the vpn trigger list or else all hotspot detection would be broken. It
> seems they have switched to captive.apple.com with returns "Success". It
> has a TTL of 10 (after a CNAME redirect into Akamai) but it is missing
> a  record. Guess there aren't many ipv6 captive portals yet :P

Using http://apple.com/[anything] is an extra-terrible idea because
it's rather fundamentally incompatible with HSTS unless you fudge it
client-side to ignore HSTS.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)

[Andrew Lutomirski]

On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač  wrote:
> Hello,
>
> On Jun 13, 2015 4:28 AM, "Michael Catanzaro"  wrote:
>> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
>> > >
>> > But that's not even right.  Suppose you have a captive portal that
>> > wants you to log in via your Google account.  It can send you do
>> > https://accounts.google.com, and your browser can verify the
>> > certificate and show you an indication that the connection is secure.
>> > Then you really can safely enter your password.
>>
>> Hmmm, I didn't realize legitimate portals might take you to the public
>> Internet.
>
> I think I've seen this in airports and in some hotel chains.
>
> Yes; sadly, many “legitimate portals” (easily 50% of the airport hotspots I
> have encoutered in Europe) are pretty much attackers.
>
> In particular, many of them want to bypass hotspot detection so that the log
> in screen does not appear in the sandboxed hotspot sign-on browser; by now
> it is a pretty standard feature of business access points to have a “bypass
> hotspot detection” checkbox. (For iOS, this has reportedly been done by
> recognizing an unique User-Agent used for the hotspot check; not sure about
> Android.)¹
>
> They want to use the regular, unsandboxed, browser so that
>
> password autofill works
> credit card number autofill works
> your Facebook login state is available to that you can easily “like” the
> hotspot provider (I’m not entirely sure but I think I did already see “like
> our page for 15 minutes of free internet” in a public hotspot)
> your advertising tracking cookies transfer (for better targeting of ads on
> the hotspot login page, or so that you can be marked “visited airport $ABC”
> and related ads can be targeted at you in the future)
>
> What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider
> deliberately let the hotspot probe lookup and connection through, but kept
> redirecting everything else?
>Mirek

Detect it and show the sandboxed browser.  If that means that the user
has to type their Facebook password again, then the user is welcome to
do that.  I don't see why we should make it easier to track users,
though.

Or we could proxy all traffic through the giant hole they'll create in
order to avoid being detected as a captive portal.  /me ducks

We could at least make these shenanigans harder by sending a
legitimate-looking UA header and hitting a non-static page that
answers some challenge rather than just saying "200 OK".

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Audit overhead and default rules

[Andrew Lutomirski]

On a default Fedora installation, every system call incurs a fair
amount of overhead due to syscall auditing.  This happens despite the
fact that syscalls aren't actually audited, except as part of AVC
denials.

The overhead is something like 20-40ns per syscall, and the total time
to do a simple syscall with auditing completely disabled is about 70ns
on my laptop.  So this is actually a large effect.

What would people think about changing the default audit rules to add
something like '-t task,never'?  This would remove the overhead, but
it would come at the cost of removing the syscall records from
/var/log/audit/audit.log when an AVC denial occurs.

This could make debugging selinux errors a bit harder, but it would be
easy for users to re-enable full auditing.

I've been playing with fixing this in the kernel, but it's a mess.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Audit overhead and default rules

[Andrew Lutomirski]

On Mon, Feb 10, 2014 at 12:06 PM, Steve Grubb  wrote:
> On Monday, February 10, 2014 11:05:38 AM Andrew Lutomirski wrote:
>> On a default Fedora installation, every system call incurs a fair
>> amount of overhead due to syscall auditing.  This happens despite the
>> fact that syscalls aren't actually audited, except as part of AVC
>> denials.
>>
>> The overhead is something like 20-40ns per syscall, and the total time
>> to do a simple syscall with auditing completely disabled is about 70ns
>> on my laptop.  So this is actually a large effect.
>
> Then pass -s=nochange on the auditd command prompt. This means that auditd
> will not attempt to enable auditing. When auditing is not enabled, it will not
> build an audit context and syscalls are slightly faster, but you will loose a
> tiny bit of information that selinux would have liked to have.
>
>
>> What would people think about changing the default audit rules to add
>> something like '-t task,never'?
>
> This filter is almost useless. Its never used in real life because it creates
> inauditable processes which is exactly opposite of what people normally want.

It's also the only way to turn off TIF_SYSCALL_AUDIT in current
kernels.  I'm not attempting to justify the sanity of that; I'm just
reading the code.

>
>>  This would remove the overhead, but it would come at the cost of removing
>> the syscall records from
>> /var/log/audit/audit.log when an AVC denial occurs.
>>
>> This could make debugging selinux errors a bit harder, but it would be
>> easy for users to re-enable full auditing.
>>
>> I've been playing with fixing this in the kernel, but it's a mess.
>
> Its also simple to fix in your config.

There are, indeed, many ways for me to fix this on my machine.  I'm
suggesting that Fedora change the default so that no one has
experiences this overhead by default.  If the default gets changed, I
don't particularly care *which* change is made, so long as the effect
is that TIF_SYSCALL_AUDIT doesn't get set (so there's no overhead) but
that AVC denials still get logged (which I suspect is the overwhelming
majority of the value added by audit support).

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Audit overhead and default rules

[Andrew Lutomirski]

On Mon, Feb 10, 2014 at 12:26 PM, Steve Grubb  wrote:
> On Monday, February 10, 2014 12:10:27 PM Andrew Lutomirski wrote:
>> On Mon, Feb 10, 2014 at 12:06 PM, Steve Grubb  wrote:
>> > On Monday, February 10, 2014 11:05:38 AM Andrew Lutomirski wrote:
>> >> On a default Fedora installation, every system call incurs a fair
>> >> amount of overhead due to syscall auditing.  This happens despite the
>> >> fact that syscalls aren't actually audited, except as part of AVC
>> >> denials.
>> >>
>> >> The overhead is something like 20-40ns per syscall, and the total time
>> >> to do a simple syscall with auditing completely disabled is about 70ns
>> >> on my laptop.  So this is actually a large effect.
>> >
>> > Then pass -s=nochange on the auditd command prompt. This means that auditd
>> > will not attempt to enable auditing. When auditing is not enabled, it will
>> > not build an audit context and syscalls are slightly faster, but you will
>> > loose a tiny bit of information that selinux would have liked to have.
>> >
>> >> What would people think about changing the default audit rules to add
>> >> something like '-t task,never'?
>> >
>> > This filter is almost useless. Its never used in real life because it
>> > creates inauditable processes which is exactly opposite of what people
>> > normally want.
>>
>> It's also the only way to turn off TIF_SYSCALL_AUDIT in current
>> kernels.  I'm not attempting to justify the sanity of that; I'm just
>> reading the code.
>
> Not enabling audit also causes TIF_SYSCALL_AUDIT to not be placed in the
> process's flags. You have 2 choices: 1) performance  2) audit.  They are
> necessarily mutually exclusive.
>
>
>> >>  This would remove the overhead, but it would come at the cost of
>> >>  removing
>> >>
>> >> the syscall records from
>> >> /var/log/audit/audit.log when an AVC denial occurs.
>> >>
>> >> This could make debugging selinux errors a bit harder, but it would be
>> >> easy for users to re-enable full auditing.
>> >>
>> >> I've been playing with fixing this in the kernel, but it's a mess.
>> >
>> > Its also simple to fix in your config.
>>
>> There are, indeed, many ways for me to fix this on my machine.  I'm
>> suggesting that Fedora change the default so that no one has
>> experiences this overhead by default.
>
> There are 3 levels of audit performance degradation.
> 1) audit is disabled. You get full speed
> 2) audit is enabled and no rules. This is the default for Fedora so that more
> information can be collected when AVC's occur.
> 3) audit is enabled and rules loaded. This does get a performance hit that can
> be measured. In this case, the person wanted auditing and is willing to take
> any performance hit it may incur.
>
> The audit system has been set for #2 for the last 8 or 9 years as a balance
> between getting information for avc's, not taking a big performance hit, and
> keeping setup easy for when people want to add auditing to their system.
>

Right.  I'm proposing changing the default from #2 to #1.  I think
that #2-by-default is a terrible tradeoff.  I suspect I've debugged
more selinux denials than the average user, and I have *never* *once*
looked at a 'syscall' entry in the log.  I think that subjecting every
Fedora user by default to 20-40 ns of extra syscall latency for the
sole benefit of getting those 'syscall' messages is a bad tradeoff.

I'm willing to write kernel code to improve the situation.  The
problem is that getting rid of TIF_SYSCALL_AUDIT when there are no
audit rules configured is messy.  Better suggestions are welcome.

>
>> If the default gets changed, I
>> don't particularly care *which* change is made, so long as the effect
>> is that TIF_SYSCALL_AUDIT doesn't get set (so there's no overhead) but
>> that AVC denials still get logged (which I suspect is the overwhelming
>> majority of the value added by audit support).
>
> AVC's should be logged with or without audit being enabled. Auditd will
> collect any avc sent to it by selinux even if audit is disabled. Please try
> adding -s=nochange to your config and see how that works for you.

I will not be at all surprised if it works.

>
> -Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Audit overhead and default rules

[Andrew Lutomirski]

On Mon, Feb 10, 2014 at 1:02 PM, Steve Grubb  wrote:
> On Monday, February 10, 2014 12:41:08 PM Andrew Lutomirski wrote:
>> >> There are, indeed, many ways for me to fix this on my machine.  I'm
>> >> suggesting that Fedora change the default so that no one has
>> >> experiences this overhead by default.
>> >
>> > There are 3 levels of audit performance degradation.
>> > 1) audit is disabled. You get full speed
>> > 2) audit is enabled and no rules. This is the default for Fedora so that
>> > more information can be collected when AVC's occur.
>> > 3) audit is enabled and rules loaded. This does get a performance hit that
>> > can be measured. In this case, the person wanted auditing and is willing
>> > to take any performance hit it may incur.
>> >
>> > The audit system has been set for #2 for the last 8 or 9 years as a
>> > balance
>> > between getting information for avc's, not taking a big performance hit,
>> > and keeping setup easy for when people want to add auditing to their
>> > system.
>>
>> Right.  I'm proposing changing the default from #2 to #1.
>
> I forgot to mention option 0) audit package not installed. I don't think the
> audit package is mandatory and that would be the default. But if you do
> install the audit package its assumed you want auditing in some capacity and
> are willing to take the minimal hit. You also get more audit events such as
> promiscuous socket use, user space events, and a couple other kernel events
> that are security related.
>
>> I think that #2-by-default is a terrible tradeoff.  I suspect I've debugged
>> more selinux denials than the average user, and I have *never* *once*
>> looked at a 'syscall' entry in the log.
>
> The selinux people wanted the syscall event. Once upon a time, you used to
> have to add a rule to get the syscall information. But they decided they want
> more information by default. I would suggest reverting that patch as a test. I
> think the problem was that they needed a file path sometimes and would ask
> people to add an audit rule like "-w /etc/shadow -p w". But then the user
> wouldn't get a recurrence and they couldn't really fix the problem very fast.
> The exact details may be different, but I think this is the gist of it.
>

Here's an example from my logs:

type=AVC msg=audit(1383816002.656:3662): avc:  denied  { execute } for
 pid=32707 comm="sh" name="ldconfig" dev="dm-2" ino=172883
scontext=system_u:system_r:smoltclient_t:s0-s0:c0.c1023
tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1383816002.656:3662): arch=c03e syscall=59
success=no exit=-13 a0=9c0d30 a1=9c0e00 a2=9bfd70 a3=0 items=0
ppid=32706 pid=32707 auid=999 uid=999 gid=998 euid=999 suid=999
fsuid=999 egid=998 sgid=998 fsgid=998 ses=415 tty=(none) comm="sh"
exe="/usr/bin/bash"
subj=system_u:system_r:smoltclient_t:s0-s0:c0.c1023 key=(null)

The useful things (I think) are "dev" and "ino", both of which are in
the AVC line, not the syscall line.

>
>> I think that subjecting every Fedora user by default to 20-40 ns of extra
>> syscall latency for the sole benefit of getting those 'syscall' messages is a
>> bad tradeoff.
>
> I don't think all Fedora users have audit installed and would not see the hit.

From the F20 comps:

  
core
<_name>Core
<_description>Smallest possible installation
false
false

  audit

audit is the very first mandatory package :-/

>
>> I'm willing to write kernel code to improve the situation.  The
>> problem is that getting rid of TIF_SYSCALL_AUDIT when there are no
>> audit rules configured is messy.  Better suggestions are welcome.
>
> The problem is getting TIF_SYSCALL_AUDIT back in all processes when auditing
> is enabled. We cannot stop the OS and stab that flag into all processes when
> audit gets re-enabled. Its best not to play with that flag.

Sure we can.  I have patches to do that.  They have other problems,
though, but that's fixable.

>
> The kernel logic is supposed to be something like
>
> if (tif & TIF_SYSCALL_AUDIT)
>   if (current->audit_context)
> if (audit_ever_enabled)
>   audit_syscall_entry()
>
> So, the overhead when disabled should only be an if statement or two.

On my laptop it's up to 1/3 of *total* syscall time.  Linux fast-path
syscalls are fast, and audit disables the fast path.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

yum upgrade creates /var/run/nologin

[Andrew Lutomirski]

This has happened twice now.  I run 'yum upgrade' and, all of a
sudden, /var/run/nologin exists.  It contains a message telling me
that my system is still booting.  This is, of course, a lie -- the
system has been up for quite a while, *and I'm logged in with the
screen locked*.

This is rather impolite.  /var/run/nologin isn't owned by any package,
so I have no clue where to file the bug.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages with missing %check

[Andrew Lutomirski]

On Tue, Feb 25, 2014 at 2:38 PM, Richard W.M. Jones  wrote:
> On Tue, Feb 25, 2014 at 03:45:51PM +0100, Matthias Runge wrote:
>> On Tue, Feb 25, 2014 at 08:50:18AM -0500, Adam Jackson wrote:
>> > On Tue, 2014-02-25 at 12:45 +0200, Alexander Todorov wrote:
>> >
>> > > 1) Do we consider this a bug and if yes what priority do you give it? 
>> > > From last
>> > > week discussions it looks like most people prefer to have tests executed 
>> > > in %check.
>> >
>> > I don't consider %check to be an appropriate way to run tests, so no, I
>> > don't consider it a bug.  Stating it broadly: we don't have a separate
>> > phase for it in koji, which means we can't adequately set up tests in
>> > general; and adding it to koji would be a mistake, because build
>> > construction and build validation are fundamentally different phases.
>> >
>> > This is an argument against %check, not against testing in general.  We
>> > should be relying on rpmbuild less, not more.  rpm doesn't even have
>> > anything like Requires(check), does it?
>>
>> Hmm, then we should probably about enhancing this? Like adding a
>> separate phase of for %check to rpmnbuild?
>
> There is a proposal to allow better testing of packages, and groups of
> packages.  Actually at least two proposals but the one I'm thinking of
> now is:
>
>   https://fedoraproject.org/wiki/Taskotron
>
> Previous discussion:
>
>   https://lists.fedoraproject.org/pipermail/devel/2013-December/193267.html
> & 
> https://lists.fedoraproject.org/pipermail/devel/2014-January/thread.html#193521
>
>> IMHO, that still belongs to building a package, as I don't want
>> a package pushed, when checks are not executed successfully.
>
> Some testing can be done in %check, and some testing needs to be done
> outside %check because either it involves multiple packages, or
> because it's too heavyweight for %check, or because it involves some
> extra permissions (eg. root, a VM, etc).

Just to mention: there are probably many packages where the equivalent
of %check can't be run without access to a source tree, so Taskotron
can't usefully replace %check.  I maintain a package like that.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 9:22 AM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: System-wide crypto policy =
> https://fedoraproject.org/wiki/Changes/CryptoPolicy
>
> Change owner(s): Nikos Mavrogiannopoulos 
>
> Unify the crypto policies used by different applications and libraries. That 
> is
> allow setting a consistent security level for crypto on all applications in a
> Fedora system.
>
> == Detailed Description ==
> The idea is to have some predefined security levels such as LEVEL-80,
> LEVEL-128, LEVEL-256,
> or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
> security levels
> that the administrator of the system will be able to configure by modifying
> /usr/lib/crypto-profiles/config
> /etc/crypto-profiles/config

How much of the system will break if the administrator does something
silly like setting LEVEL-256?

For reference, there isn't a well-established, widely accepted
symmetric cipher with 256-bit security.  AES-256 is weak [1] and
should probably not be used at all, let alone by anyone who wants a
256-bit security level.  3-DES is slow and doesn't offer 256-bit
security. Salsa20 and ChaCha20 are probably okay for 256-bit security,
but they aren't widely supported yet.

This means that sensible websites (and browsers!) don't enable the
AES-256 cipher suites.  Should a system set to LEVEL-256 disallow
access to those sites?  What about disallowing use of CA certificates
that use SHA-1?  (Oops, there goes the Internet.)

If someone sets SUITEB-whatever, is Curve25519 acceptable?

How many people even know what an ENISA algorithm is?  (I don't.)

I would maybe support a division into "probably already broken by
people with deep pockets" (e.g. DES, RC4, MD5, maybe SHA-1 in some use
cases), "probably safe against classical computers for a long time"
(everything at 128 bits or higher, RSA with, say, 3072 bits and up,
maybe RSA2048, and Suite B, depending on your philosophical views),
and "probably safe against quantum computers for a long time"
(Probably Salsa20, ChaCha20, and a handful of public-key cryptosystems
that are either patent-encumbered, insecure, impractical, or more than
one of the above.)

Alternatively, a systemwide setting like "avoid modp groups below X
bits" could make sense.  Far too many things 1024-bit modp groups.
This includes *SSH* until very recently.  Having a single switch to
turn that cr*p off would be very useful, although it might imply a lot
of patches.

[1] https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 10:49 AM, Nikos Mavrogiannopoulos
 wrote:
> On Thu, 2014-02-27 at 10:12 -0700, Andrew Lutomirski wrote:
>> > == Detailed Description ==
>> > The idea is to have some predefined security levels such as LEVEL-80,
>> > LEVEL-128, LEVEL-256,
>> > or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
>> > security levels
>> > that the administrator of the system will be able to configure by modifying
>> > /usr/lib/crypto-profiles/config
>> > /etc/crypto-profiles/config
>> How much of the system will break if the administrator does something
>> silly like setting LEVEL-256?
>
> Probably a lot, but I don't think we protect from someone doing rm -fr /
> either :)
>
>> For reference, there isn't a well-established, widely accepted
>> symmetric cipher with 256-bit security.  AES-256 is weak [1] and
>> should probably not be used at all, let alone by anyone who wants a
>> 256-bit security level.
>
> AES-128 is broken too:
> http://www.kuleuven.be/english/newsletter/newsflash/encryption_standard.html
>
> (in short it provides 126-bit security instead of 128).
>
> _However_, this and the attacks your describe on AES-256 don't matter
> for practical purposes. Schneier explains in the blog you quote, but I
> recap:
>
> 1. Related key attacks are nice for publishing papers, but they have
> almost no practical relevance (AES or any other modern cipher isn't
> designed to resist related key attacks).
> 2. Attacking on reduced round variants of ciphers, doesn't matter either
> except for academics and for getting the future trend of security of the
> cipher. We use the full-round variants that resist the published
> attacks.
> 3. Breaking a cipher in the academic term means finding an attack that
> is faster than brute force. The brute force level of AES-256 is terribly
> high so "breaking" AES-256 in 2^245 steps is still very reassuring.

So, in summary:

 - LEVEL-256 provides well under 256-bit security.
 - This is fine because no one actually needs 256-bit security.

So *why on earth* would it make sense to implement this proposal?  It
sounds like we'd be offering options that (a) don't perform as
advertised and (b) don't serve any purpose anyway.

>
>> access to those sites?  What about disallowing use of CA certificates
>> that use SHA-1?  (Oops, there goes the Internet.)
>
> We have to document that, but there will be always ways to shoot
> someones foot. There are legitimate uses of increasing a security level
> (if one for example sets up machines to be used in a LAN).
>
>> If someone sets SUITEB-whatever, is Curve25519 acceptable?
>
> SuiteB only allows two curves. SECP256 and SECP384 if I remember well.

I understand why people implement ridiculous FIPS modes: it's to
comply with government rules.  I don't see why Fedora should add to
the mess.

>
>> How many people even know what an ENISA algorithm is?  (I don't.)
>
> ENISA is not an algorithm. It is the "European Union Agency for Network
> and Information Security" and they have some papers proposing various
> security levels, similarly to NIST. https://www.enisa.europa.eu/
>
>> Alternatively, a systemwide setting like "avoid modp groups below X
>> bits" could make sense.  Far too many things 1024-bit modp groups.
>> This includes *SSH* until very recently.  Having a single switch to
>> turn that cr*p off would be very useful, although it might imply a lot
>> of patches.
>
> That's the idea.

Then let's do that.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Andrew Lutomirski]

On Thu, Feb 27, 2014 at 10:26 AM, Stephen John Smoogen  wrote:
>
>
>
> On 27 February 2014 10:58, Andrew Lutomirski  wrote:
>>
>>
>> > We have to document that, but there will be always ways to shoot
>> > someones foot. There are legitimate uses of increasing a security level
>> > (if one for example sets up machines to be used in a LAN).
>> >
>> >> If someone sets SUITEB-whatever, is Curve25519 acceptable?
>> >
>> > SuiteB only allows two curves. SECP256 and SECP384 if I remember well.
>>
>> I understand why people implement ridiculous FIPS modes: it's to
>> comply with government rules.  I don't see why Fedora should add to
>> the mess.
>>
>
> Because such .gov rules are pushing throughout the industry and university
> systems. You may be a research professor who has a grant which requires you
> to show your systems are on such level as someone in the granting agency
> doesn't want its grants to have stored their records in plain text or worse
> the algorithms the professor knew back in the 1970's when he was a grad
> student. [Been there, done that] You may be a university hospital which has
> to show that it is keeping confidentiality through various levels [Fedora
> like many linuxes gets used to be embedded in hardware you might scratch
> your head but it is what it is.] You may be a EU giant accelerator which
> finds that its funding has new riders and while you don't use Fedora, you
> use a rebuild and will want to show you can meet those riders in X years
> (which is usually good enough for the financial auditors).
>
> It is basically to help make the work easier so that when someone is told
> you have to make your system compliant they can do it in one spot versus
> 500.

In that case, why not give full control:

allowed_ciphers = AES-192, AES-256, Salsa20/12, Salsa20/20
allowed_groups = modp >= 2048, P-256, Curve25519
allowed_hashes = SHA-3, ...
allowed_modes = CTR, OCB, XTS, GCM
allowed_macs = ...

If the point is to comply with requirements that we don't even know
about yet, then allowing LEVEL-256 to mean "256 bits or more, by some
particular mapping between modp length and bits, and, oh, by the way,
AES-256 is okay" is asking for this thing to end up being useless.

Also, please keep this proposal the heck away from my desktop box.

On the other hand, if something can warn about the use of particular
primitives, that would be great -- it might have caused people to
notice the IMO disastrous OpenSSH 1024-bit crap much sooner.  I
suspect that several governments know a lot of my passwords as a
result of that screwup.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Andrew Lutomirski]

On Fri, Feb 28, 2014 at 2:52 AM, Nikos Mavrogiannopoulos
 wrote:
> On Thu, 2014-02-27 at 10:58 -0700, Andrew Lutomirski wrote:
>
>>
>>  - LEVEL-256 provides well under 256-bit security.
>>  - This is fine because no one actually needs 256-bit security.
>>
>> So *why on earth* would it make sense to implement this proposal?  It
>> sounds like we'd be offering options that (a) don't perform as
>> advertised and (b) don't serve any purpose anyway.
>
> I don't really understand what you are arguing about. Are you
> complaining that AES-256 doesn't offer the advertized 256-bit security,
> or that a consistent security policy isn't required?

I'm arguing that there is no sensible setting.  If you want 256-bit
security as your "consistent security policy", then either (a) you
won't actually get 256-bit security or (b) you won't have any legal
well-tested block ciphers at all.  Saying that AES-256 is good enough
is specious: if the administrator ask for "256-bit" security and if
you assume that giving the administrator this kind of control makes
sense in the first place, then you should interpret the
administrator's request to mean, literally, 256 bits.  In particular,
reinterpreting the request to mean "256 bits would be nice, but 245 is
okay, and maybe other numbers are okay too depending on whether
related key attacks are relevant" is, IMO, a terrible idea.


On Fri, Feb 28, 2014 at 2:59 AM, Nikos Mavrogiannopoulos
 wrote:
> On Thu, 2014-02-27 at 10:37 -0800, Andrew Lutomirski wrote:
>> In that case, why not give full control:
>> allowed_ciphers = AES-192, AES-256, Salsa20/12, Salsa20/20
>> allowed_groups = modp >= 2048, P-256, Curve25519
>> allowed_hashes = SHA-3, ...
>> allowed_modes = CTR, OCB, XTS, GCM
>> allowed_macs = ...
>
> Because of two reasons:
> 1. A typical administrator isn't a cryptographer. Most people cannot
> distinguish noise from the algorithms that you mention above.
>
> 2. That proposal has to work with very different libraries that don't
> provide the same level of access to their internals.

Now you and smooge appear to want different things out of this
proposal.  smooge wants to comply with arcane governmental rules,
which, for better or for worse, are probably fairly specific.  In that
case, just saying LEVEL=whatever will not solve the problem.

What is the actual point of this proposal?  What is it trying to
accomplish?  Why is whatever it's trying to accomplish something that
Fedora should be interested in?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20: what connects the lid switch to triggering suspend?

[Andrew Lutomirski]

On Thu, Mar 13, 2014 at 3:07 PM, Martin Langhoff
 wrote:
> My Lenovo X220, running up-to-date F20 occasionally gets into a state where
> closing the laptop lid does not trigger suspend.
>
> I want to narrow down on the problem, but I'm slightly lost on how
> "the signal is routed" through the stack. udev->?-> systemd-suspend ->
> kernel  ?

I wonder whether this is related to the fact that, on most Lenovos, if
you press the suspect button twice without waiting long enough, the
second press is ignored.

--Andy, wearing his very-occasional-lenovo-driver-hacker hat

>
> thank you!
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  -  ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
 wrote:
> On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>
>> > Fedora takes a different approach though, and will mount an explicit
>> > boot partition to /boot and the ESP to /boot/efi, and do so
>> > unconditionally without involving autofs.  Fedora could add
>> > "x-systemd-automount" to the mount options of /boot/efi, and thus
>> > turning /boot/efi into an autofs too.
>>
>> When I add x-systemd.automount to fstab for /boot/efi, it still gets
>> mounted on every boot.
>
> Ah, yeah sorry, forgot to mention, you need to also add "noauto" to the
> line. If it is "auto" we'll still wait for the mount unit to complete.
>
> Basically, combining x-systemd.automount + auto is just a away to speed
> up boot by fscking in the bg while the mount point is already
> established. After boot the file system will be mounted as if
> x-systemd.automount hadn't been used.
>
> Combining x-systemd.automount + noauto however is a way to establish a
> mount point and only lazily triggering it on access. And that's what you
> want to use here.

It seems like 'ls /boot/efi' shouldn't be enough to trigger a mount --
the poi nt is that /boot/efi should stay unmounted unless there's a
genuine need to mount it.  So just plain noauto might be good enough
here (i.e. without the automount).

I'm usually a fan of giving mountpoints mode 000 to avoid accidentally
using them when unmounted, but that doesn't really do anything for
root.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Tue, Mar 18, 2014 at 6:07 PM, Adam Williamson  wrote:
> On Tue, 2014-03-18 at 17:27 -0700, Andrew Lutomirski wrote:
>> On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
>>  wrote:
>> > On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>> >
>> >> > Fedora takes a different approach though, and will mount an explicit
>> >> > boot partition to /boot and the ESP to /boot/efi, and do so
>> >> > unconditionally without involving autofs.  Fedora could add
>> >> > "x-systemd-automount" to the mount options of /boot/efi, and thus
>> >> > turning /boot/efi into an autofs too.
>> >>
>> >> When I add x-systemd.automount to fstab for /boot/efi, it still gets
>> >> mounted on every boot.
>> >
>> > Ah, yeah sorry, forgot to mention, you need to also add "noauto" to the
>> > line. If it is "auto" we'll still wait for the mount unit to complete.
>> >
>> > Basically, combining x-systemd.automount + auto is just a away to speed
>> > up boot by fscking in the bg while the mount point is already
>> > established. After boot the file system will be mounted as if
>> > x-systemd.automount hadn't been used.
>> >
>> > Combining x-systemd.automount + noauto however is a way to establish a
>> > mount point and only lazily triggering it on access. And that's what you
>> > want to use here.
>>
>> It seems like 'ls /boot/efi' shouldn't be enough to trigger a mount --
>> the poi nt is that /boot/efi should stay unmounted unless there's a
>> genuine need to mount it.  So just plain noauto might be good enough
>> here (i.e. without the automount).
>
> Um. What? How would it then get automounted?
>

Exactly.  What needs it to automount and why?  Isn't Chris's main
point that Fedora shouldn't neet to mount the ESP in the first place?

I can see an argument for (auto)mounting it readonly, though.


> You need 'noauto' to tell systemd not to mount it on boot, and
> 'x-systemd-automount' (when did that change from
> 'comment=systemd.automount'?) to tell systemd to automount it on access.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Wed, Mar 19, 2014 at 3:53 PM, Lennart Poettering
 wrote:
> On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote:
>
>> I agree, although I go farther. The EFI System partition doesn't
>> scale, isn't resilient, can neither be mirrored nor easily sync'd
>> (multidevice boot). It should be considered a pre-boot and OS
>> installer domain only.
>
> You know, the ESP is actually FAT, one of the simplest, best-understood,
> most used, and most stable file systems around. Sure, one can always
> break things, but it is simply misguided to believe that this is the
> part that will likely break and that we really really really need to
> stay away from, and not the later parts of the boot that involve grub
> and raid, and yuck.
>
> You know, by creating a chain of many steps where you first go for
> the ESP, and then follow that by another boot partition and so on, you
> just make things more complex.

More complex than trying to mirror a FAT ESP partition across multiple
boot disks, keeping it properly synchronized, because RAID isn't
supported?

Grub 1 on MD RAID actually just works, once you figure out the
incantation to install it.  It would be a shame if that ability got
lost in the name of simplicity.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Thu, Mar 20, 2014 at 9:32 AM, Przemek Klosowski
 wrote:
> On 03/20/2014 01:21 AM, Chris Murphy wrote:
>> You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
>> of how RAID-1 works; each individual member can also be mounted as if it
>> was just a plain old partition, which is how the firmware will mount it.
>
> This shouldn't be done. It's a source of corruption to treat an md raid1
> device as a plain volume, rather than as a degraded md device. If the plain
> partition volume is modified, its mdadm metadata won't be updated, so when
> the array is finally assembled, mdadm has no idea member devices are not
> sync'd, and also has no way to resolve the ambiguity.
>
> Right, but UEFI doesn't write to itit just uses them to read the boot
> content. It would be better if UEFI could read software raid1 even if it was
> degraded due to disk failures, but apparently it can't, so Adam's scheme is
> the only possibility.

Um.

EFI_FILE_PROTOCOL's Write method sounds suspiciously like it writes to
a filesystem.

>>
>> Because of this, at least one raid stack kernel maintainer wants to do away
>> with the use of mdadm metadata v 1.0 by anaconda. It's v1.0 metadata that
>> permits this plain old  partition treatment as a side effect.
>
> It is a darn useful side effect. How else can you implement redundant boot
> that is transparently updated? I could (and did) try
> multiple /boot partitions on separate drives by copying the partition
> content after updates, but it was fragile and I was never confident that it
> would work when I needed it. Adam's raid1 /boot just seems more reliable,
> especially if it became a designed feature.
>

I think you may be confusing /boot and ESP (aka /boot/efi).  They are
not the same thing.

You get a transparently updated list of kernels by doing it exactly
the way that Chris suggested.  You have /boot on md raid with metadata
1.1 or 1.2.  Or you have /boot on any other sensible RAID backing
store, where sensible means that everything that mounts it knows that
it's RAID.

Then you stick something *that never changes* into each copy of the
ESP.  And you don't even pretend that ESP is RAID -- it's simply a
bunch of FAT filesystems that *are not mounted read/write* except for
when the bootloader is reinstalled.  And you do *not* reinstall the
bootloader just because you have a new kernel.

All of the RAID devices are only ever accessed by RAID drivers.  All
of the ESP non-RAID filesystems are treated as the crappy FAT
filesystems that they are and are almost never written by Linux
userspace.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson  wrote:
> On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
>
>> Adam's scheme is the only possibility.
>
>> Adam's raid1 /boot just seems more
>> reliable, especially if it became a designed feature.
>
> It's not my plan, it's the anaconda developers'. I only described it.
> Actually it took them like 15 minutes to get it into my dumb brain. :)

Can you all please try to make sure you're talking about the same thing?

I believe that Chris is suggesting /boot as raid1 and ESP not mounted.

Adam and Przemek seem to be talking about /boot on RAID1 (I've never
heard anyone say that /boot as RAID is a bad idea) but I think
something's very confused about my understanding of your opinions
about how the ESP should or does work.  Can one or both of you please
describe, unambiguously, how you think the ESP should be created, when
and if it should be mounted, what filesystem and/or raid config should
be used to mount it, and what should happen when a kernel is updated?

> Sure, UEFI has the capability, but it's not going to be used when simply
> booting the system normally. All the firmware does in that case is mount
> the partition and execute the bootloader it finds there.

Why not?  It's completely safe when the OS is Mac OS or Windows.  It's
sometimes safe when the OS is Linux.  It's even possibly useful: you
might want to have an ESP bootloader, shim, or whatever that logs
errors.  I bet there's at least one UEFI firmware out there that backs
up settings to ESP and/or backs up a whole firmware image to ESP.

It would be a shame for a Linux "RAID" install to corrupt the ESP just
because you did something unusual in various UEFI menus.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rfc: EFI System partition, FAT32, repair and non-persistent mount

[Andrew Lutomirski]

On Thu, Mar 20, 2014 at 10:07 AM, Andrew Lutomirski  wrote:
> On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson  wrote:
>> Sure, UEFI has the capability, but it's not going to be used when simply
>> booting the system normally. All the firmware does in that case is mount
>> the partition and execute the bootloader it finds there.
>
> Why not?  It's completely safe when the OS is Mac OS or Windows.  It's
> sometimes safe when the OS is Linux.  It's even possibly useful: you
> might want to have an ESP bootloader, shim, or whatever that logs
> errors.  I bet there's at least one UEFI firmware out there that backs
> up settings to ESP and/or backs up a whole firmware image to ESP.
>
> It would be a shame for a Linux "RAID" install to corrupt the ESP just
> because you did something unusual in various UEFI menus.

The standard EFI Shell can do exactly this.  It has commands like
'edit' and 'mkdir'.  I think that using them should not cause
filesystem corruption.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [CHANGE PROPOSAL] The securetty file is empty by default

[Andrew Lutomirski]

On Thu, Apr 3, 2014 at 2:46 PM, Przemek Klosowski
 wrote:
> On 04/03/2014 10:32 AM, quickbooks office wrote:
>
> "3.1.4.2.2. Disabling Root Logins
>
> To further limit access to the root account, administrators can
> disable root logins at the console by editing the /etc/securetty file.
>
> This is done in the name of accountability, by forcing an administrative
> login through an account attributable to a specific person. This, however,
> only makes sense if there _actually_are_ such individual accounts on the
> system.
>
> Would this proposal be acceptable if it wasn't implemented if 'root' is the
> only account?
>
> I personally don't think even such amended proposal is a reasonable default
> configuration, because systems authenticating against a domain, and having
> only one local (root) account, could lock the admin out if something happens
> to the network or to the domain server.
>

It's worse: the admin could lock themselves out just by creating
another user account.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reinstalling the bootloader

[Andrew Lutomirski]

Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.

Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is
there a way to reinstall it without reinstalling the world?  Would it make
sense to split the whole bootloader thing out of Anaconda such that it
would be possible to re-run it?  I can access my install just fine using
chroot.

FWIW, the same question applies to upgrading the bootloader.  Somehow I'm
on Fedora 20 using grub 0.97.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Apr 3, 2014 7:18 PM, "Reindl Harald"  wrote:
>
>
>
> Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
> > Once upon a time (Fedora 15? -- I've lost track), it was possible to 
> > reinstall the bootloader using grub-install.
>
> besides that it is the wrong list:

What's the right list?

> grub2-install

$ grub2-install
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1.
Check your device.map.

This is with efi.  WTF is a GRUB drive?  Will this set up the boot
menu in anything resembling a sensible manner?  (I doubt it, since I
don't consider having kernel entries listed in the ESP to be sensible,
but that's a separate issue.)  Will it set up EFI boot manager
entries?  Is the efibootmgr program usable by mortals?

For non-EFI, I have to do some i386-pc crap.  At least I think I have
some idea how that's supposed to work.

FWIW, the last time I got grub2-mkconfig to work, it generated a
config that, strictly speaking, functioned, but it spewed warnings
every time I booted.  That was a while ago.

>
> > Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is 
> > there a way to reinstall it without
> > reinstalling the world?  Would it make sense to split the whole bootloader 
> > thing out of Anaconda such that it would
> > be possible to re-run it?  I can access my install just fine using chroot.
> >
> > FWIW, the same question applies to upgrading the bootloader.  Somehow I'm 
> > on Fedora 20 using grub 0.97
>
> how comes? grub2 took over with F16 or F17
>

Upgrades.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Thu, Apr 3, 2014 at 8:09 PM, Ankur Sinha  wrote:
> On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote:
>> Once upon a time (Fedora 15? -- I've lost track), it was possible to
>> reinstall the bootloader using grub-install.
>
> Just wondering if you've read this page yet:
>
> https://fedoraproject.org/wiki/GRUB_2?rd=Grub2

I did, but this:

This is an untested write-up from memory and guessing - be careful

didn't inspire much confidence.

--Andy

>
> --
> Thanks,
> Warm regards,
> Ankur (FranciscoD)
>
> http://fedoraproject.org/wiki/User:Ankursinha
>
> Join Fedora! Come talk to us!
> http://fedoraproject.org/wiki/Fedora_Join_SIG
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Mon, Apr 7, 2014 at 5:16 PM, Adam Williamson  wrote:
> On Thu, 2014-04-03 at 19:44 -0700, Andrew Lutomirski wrote:
>> On Apr 3, 2014 7:18 PM, "Reindl Harald"  wrote:
>> >
>> >
>> >
>> > Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
>> > > Once upon a time (Fedora 15? -- I've lost track), it was possible to 
>> > > reinstall the bootloader using grub-install.
>> >
>> > besides that it is the wrong list:
>>
>> What's the right list?
>>
>> > grub2-install
>>
>> $ grub2-install
>> /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1.
>> Check your device.map.
>>
>> This is with efi.  WTF is a GRUB drive?  Will this set up the boot
>
> You don't want to be doing any kind of grub(2)-install if you actually
> have a native UEFI install. That's not how UEFI booting works. But it's
> difficult to divine from your emails how your system is actually set up
> at all.

Sorry for the delay -- I was out of town.

>
> Can you please answer the following?
>
> 1. What is the output of 'efibootmgr -v'?

$ sudo efibootmgr -v
BootCurrent: 0008
Timeout: 1 seconds
BootOrder: 0003,0008,,0001
Boot* SATA2:PLDS DVD+/-RW DH-16A6S  BIOS(10,0,00)
Boot0001* SATA1:INTEL SSDSC2BB600G4 BIOS(11,0,00)
Boot0003* grub
HD(1,800,4,75f192ff-2a82-4e4e-b83c-c41f3bb39847)File(\EFI\grub\grubx64.efi)
Boot0008* UEFI: Built-in EFI Shell
Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot000A* Hard Drive BIOS(2,0,00)AMGOAMNOo.I.N.T.E.L.
.S.S.D.S.C.2.B.B.6.0.0.G.4 A..
.>..Gd-.;.A..MQ..L.T.B.L.W.3.3.4.3.A.0.F.W.0.6.T.0.N.G.
. ... ...AMBO

This is definitely screwed up.  I can't fix it because any attempt to
change my efi variables results in an OOPS.  I can't report the OOPS
with abrt because of a correct but inconsequential kernel taint due to
#906568, which is probably fixed in 3.14.  So I was going to wait for
the 3.14 rebase or perhaps boot a custom kernel to see what helps.  I
haven't had time for that yet.

> 2. Do you have a /boot/efi/EFI/fedora/grub.cfg ?

No.  But I have a /boot/efi/EFI/redhat/grub.conf, attached.
/etc/grub.conf is a symlink to it.

That file, in turn, contains this:

device (hd1,2) HD(1,800,4,49d25af2-6f79-4970-8b9e-dc3ccf762c2c)

which I had to fix, once I figured out what UUID went there.

This file has been abused over the years by grubby.  I like
Debian/Ubuntu's way of handling this *much* better.

> 3. Do you have a /boot/grub/grub.conf ?

No.

> 4. Do you have a /boot/grub2/grub.cfg ?

No.


The immediate cause of my need to reconfigure the bootloader was that
I changed hard disks.  Imaging the partition table and fs superblocks
directly causes all manner of problems because the UUIDs will be the
same if I have both disks in the machine at the same time.  So I
copied files, and at first all I got was a grub prompt.

It's currently mostly working, modulo the efibootbgr issue.  But I
don't actually know what to type into efibootmgr to fix it, the OOPS
notwithstanding.  I can probably figure it out once the OOPS is fixed.


My point, though, is that it would be great if either the wiki had
good instructions or, even better, if anaconda's bootloader
installation process were factored out into a command I could run.

--Andy
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file.
# NOTICE:  You have a /boot partition. This means that all kernel and
#  initrd paths are relative to /boot, eg.
#  root (hd0,0)
#  kernel /vmlinuz-version ro root=/dev/sda3
#  initrd /initrd-[generic-]version.img
boot=/dev/sda1
device (hd1,2) HD(1,800,4,49d25af2-6f79-4970-8b9e-dc3ccf762c2c)
default=0
timeout=5
splashimage=(hd1,2)/grub/splash.xpm.gz
hiddenmenu
title Fedora (3.13.8-200.fc20.x86_64) 20 (Heisenbug)
root (hd1,2)
kernel /vmlinuz-3.13.8-200.fc20.x86_64 rd.md=0 rd.dm=0 
rd.lvm.lv=vg_amaluto_2014/root  KEYTABLE=us 
rd.luks.uuid=luks-1dd64d38-40c0-4e20-ad67-aa2590991023 SYSFONT=True ro 
root=/dev/mapper/vg_amaluto_2014-root LANG=en_US.UTF-8 rhgb quiet
initrd /initramfs-3.13.8-200.fc20.x86_64.img
title Fedora (3.13.7-200.fc20.x86_64) 20 (Heisenbug)
root (hd1,2)
kernel /vmlinuz-3.13.7-200.fc20.x86_64 rd.md=0 rd.dm=0 
rd.lvm.lv=vg_amaluto_2014/root  KEYTABLE=us 
rd.luks.uuid=luks-1dd64d38-40c0-4e20-ad67-aa2590991023 SYSFONT=True ro 
root=/dev/mapper/vg_amaluto_2014-root LANG=en_US.UTF-8 rhgb quiet
initrd /initramfs-3.13.7-200.fc20.x86_64.img
title Fedora (3.14.0-rc7+) 20 (Heisenbug)
root (hd1,2)
kernel /vmlinuz-3.14.0-rc7+ rd.md=0 rd.dm=0 rd.lvm.lv=vg_amaluto/root  
KEYTABLE=us rd.luks.uuid=luks-cd5b520b-745e-4a9b-bebf-d9f0

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy  wrote:
>
> You need to install or reinstall grub2-efi and shim packages.

Aha, a correct answer!  Thanks!  Based on this hint, I think I figured
it out.  I updated the
wiki accordingly.

Can you take a quick look at:
https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems

>
>
>>  I can't fix it because any attempt to
>> change my efi variables results in an OOPS.  I can't report the OOPS
>> with abrt because of a correct but inconsequential kernel taint due to
>> #906568, which is probably fixed in 3.14.  So I was going to wait for
>> the 3.14 rebase or perhaps boot a custom kernel to see what helps.  I
>> haven't had time for that yet.
>
> Make sure the firmware is up to date. And if with 3.14 and current firmware 
> you still get an oops when modifying NVRAM entries you'll want to file a bug 
> against the kernel. If it were me I'd file both on kernel.org and redhat.com 
> bugzillas with the proper cross-referencing.
>
>  It may still end up being a firmware problem that the kernel folks can't do 
> anything about, but to have a chance of it being fixed kernel side requires a 
> bug
>
>>
>>> 2. Do you have a /boot/efi/EFI/fedora/grub.cfg ?
>>
>> No.  But I have a /boot/efi/EFI/redhat/grub.conf, attached.
>> /etc/grub.conf is a symlink to it.
>
> That's what grub legacy EFI used. I forget if fedup upgrades grub on UEFI 
> systems.
>
>

>
>>
>> It's currently mostly working, modulo the efibootbgr issue.  But I
>> don't actually know what to type into efibootmgr to fix it, the OOPS
>> notwithstanding.  I can probably figure it out once the OOPS is fixed.
>
> Strictly speaking you don't need to point  UEFI non-Secure Boot computer to 
> shim.efi, you can just leave it alone and put a grub.cfg in the proper place. 
> At the grub prompt if you type set you should see either config_directory= 
> and prefix= to show where it's looking for the grub.cfg.

https://bugzilla.kernel.org/show_bug.cgi?id=73761
https://bugzilla.redhat.com/show_bug.cgi?id=1085957

>
>>  or, even better, if anaconda's bootloader
>> installation process were factored out into a command I could run.
>
> I don't understand what this means.

Being able to do:

$ sudo fedora-configure-bootloader

would be awesome.  It would probably have to take some command line arguments.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Andrew Lutomirski]

On Sat, Apr 12, 2014 at 5:18 PM, William Brown  wrote:
>
>> Now can we go back to actually discussion technical arguments again?
>
> Actually no.
>
> This whole thread has forgotten one major thing ... use cases.
>
> Proposal is to add a local caching DNS server to fedora systems. This
> may or may not accept a DHCP provided forwarder(?).
>

[snipped lots of entirely legitimate use cases]

>
> Now, in all of these cases the system local DNS cache *must* forward to
> the local DNS server. You can't at the OS distinguish between any of
> these cases with just the DHCP record or lease. It is unreasonable to
> ask everyone to manually setup DNS on every network they join. You must
> have the forwarder set to the DNS provided by DHCP so that you can
> access the local network resources. You cannot suggest bypassing these.
>

I don't think anyone is suggesting bypassing these.  That is, all of
your use cases *will still work*, possibly better than they do now,
with a systemwide resolver.

>
> Case 1: The user doesn't know much about DNS. the ISP might be reliable
> or unreliable. If we assume as discussed that the cache is flushed on
> network change, they will have an empty cache. With a good, ISP, they
> will get consistent answers to queries, and there is no point to having
> the cache.

There are two good reasons for the cache:

1. DNSSEC.  Trusting the AD bit from the ISP is wrong.

2. Caching.  It's a lot better to have a correct systemwide cache than
a bunch of per-application crappy caches.

>
> Case 3: This user does understand DNS, and they don't need DNS cache.
> They have bind / named setup, and they would like to rely on that
> instead. When they change records in their local zones, they don't want
> to have to flush caches etc. If their ISP is unreliable, or their own
> DNS is unreliable, a DNS cache will potentially mask this issue delaying
> them from noticing / solving the problem.

That's what an extremely short TTL is for.  Also, anyone relying on
local clients not caching when TTL is already terminally screwed.
Consider that Firefox, Chromium, Windows, and I suspect Mac OS and
Android have caches.  The fact that Linux command line tools have no
cache right now is not a feature.

>
> Case 8: Vpns are a bit unreliable, and have relatively high(ish)
> latency. But mostly they are quite good, ie openvpn.

Hah.  Openvpn screws up its own internal DNS cache on a regular basis
for me.  This is a common cause of Ctrl-C.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: The securetty file is empty by default

[Andrew Lutomirski]

On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim
 wrote:
> On 04/11/2014 11:18 PM, Jaroslav Reznik wrote:
>> - Original Message -
>>> = Proposed System Wide Change:  The securetty file is empty by default =
>>> https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
>>>
>>> Change owner(s):  quickbooks 
>>>
>>> The securetty file is empty by default
>>>
>>> There's on-going discussion for this Change on the devel list.
>>> https://lists.fedoraproject.org/pipermail/devel/2014-April/197344.html
>>
>> Fedora Base Working Group discussed this Change on today's meeting
>> (2014-04-11) and tends to support counter proposal to remove securetty
>> entirely from the default PAM configuration (not from distribution)
>> as discussed in the thread mentioned above. Base WG would like to ask
>> FESCo to weight it as part of decision making (once this change hits
>> FESCo meeting).
>>
> Apologies for being late to the discussion as well - just wanted to note
> that I've been running root-password-less configurations for some time
> (by using passwd -l to lock out the root account post-install), and
> later encountered this scenario whereby one of the disks failed fsck and
> I was dropped into a single-user mode login for maintenance, where I was
> prompted for... you get it, the root password.
>
> Resorted to rebooting and disabling fsck from grub, but how to handle
> fsck errors should probably be considered as part of this proposed change.

You're not the only one:

https://bugzilla.redhat.com/show_bug.cgi?id=1045574
https://bugzilla.redhat.com/show_bug.cgi?id=1087528

but I don't think that this is really related to securetty.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Andrew Lutomirski]

On Mon, Apr 14, 2014 at 9:06 AM, Dan Williams  wrote:
> On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote:
>> On Mon, 14 Apr 2014, Dan Williams wrote:
>>
>> > But another scenario I've seen:  older Netgear routers which intercept
>> > "www.routerlogin.net" as the setup page.  The instructions literally
>> > are:
>> >
>> > 1) connect your computer to the router with a cable
>> > 2) go to www.routerlogin.net
>> > 3) follow the setup guide instructions
>> >
>> > Any idea how dnssec-trigger + unbound would handle this?  Since it's
>> > router setup, maybe spawning the whole new window for the "portal" would
>> > work, but you'd want to make sure the window didn't go away or DNS
>> > didn't change until the user was done setting up the router.
>>
>> I don't know what they do when you query for anything else. If there is
>> no hotspot redirection on port 80/443 and their DNS server works
>> properly, and your wifi was secure, you would then get their forward
>> and the above would work. If it is an open wifi, we would not install
>
> Since the user is setting things up, they can pick whether it's open or
> protected wifi.  We don't control that.
>
>> the forward and you would not get there. but in the current setup, you
>> can pick "hotspot login" mode and it puts their DNS in place, and than
>> you will reach it. Note that manual hotspot login sessions require you
>
> Ok, that could be a problem.  This is a user setting up wifi on a router
> they just bought, so it has no upstream connection yet, is not yet
> configured at all, and they are just following the directions in the
> printed brochure they got with the router.  Which obviously won't say
> anything about "hotspot login" mode.
>
> Also, this is the procedure you follow if you reset the router to
> factory defaults, which support people sometimes tell you to do.  So
> we'd run into the issue if/when the user contacted Netgear technical
> support too.

If you want to get really fancy, you could try to detect a state in
which there is no connection to the internet, the router has an
address 192.168.*.1, and the router is listening on TCP port 80, and
suggest an alternate "you are connected to a possibly unconfigured
router" mode.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Mon, Apr 14, 2014 at 2:55 PM, Chris Murphy  wrote:
>
> On Apr 9, 2014, at 12:59 PM, Andrew Lutomirski  wrote:
>
>> On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy  wrote:
>>>
>>> You need to install or reinstall grub2-efi and shim packages.
>>
>> Aha, a correct answer!  Thanks!  Based on this hint, I think I figured
>> it out.  I updated the
>> wiki accordingly.
>>
>> Can you take a quick look at:
>> https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems
>
> Create a boot menu entry can be skipped if it's not a dual boot system. 
> /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default 
> on a system without an NVRAM entry already pointing to shim or grub, and a 
> fallback entry is created automagically. With Windows, yeah you probably have 
> to do something manually because it probably always boots Windows otherwise.
>

Not on my crappy motherboard :(  It apparently can't boot from
EFI/BOOT on a hard disk.  Sigh.

I tried to clarify it a bit, though.

>
>
>>>> It's currently mostly working, modulo the efibootbgr issue.  But I
>>>> don't actually know what to type into efibootmgr to fix it, the OOPS
>>>> notwithstanding.  I can probably figure it out once the OOPS is fixed.
>>>
>>> Strictly speaking you don't need to point  UEFI non-Secure Boot computer to 
>>> shim.efi, you can just leave it alone and put a grub.cfg in the proper 
>>> place. At the grub prompt if you type set you should see either 
>>> config_directory= and prefix= to show where it's looking for the grub.cfg.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=73761
>> https://bugzilla.redhat.com/show_bug.cgi?id=1085957
>
> I'm not familiar with this usage: efibootmgr -B -b 0
>
> If 0 is the same as  then that seems to ask for the removal of a fixed 
> entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. 
> But then it also shouldn't crash the kernel.
>
> A valid command would be efibootmgr -b 0003 -B
>

-B -b 0 seems to be the same as -B -b , and my  isn't the same
as your  :)  The kernel crash is something else, in any case.

>
>
>>
>>>
>>>> or, even better, if anaconda's bootloader
>>>> installation process were factored out into a command I could run.
>>>
>>> I don't understand what this means.
>>
>> Being able to do:
>>
>> $ sudo fedora-configure-bootloader
>>
>> would be awesome.  It would probably have to take some command line 
>> arguments.
>
> Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM 
> would be nice. But the NVRAM part might be a rat hole, seeing as some of the 
> manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem 
> to have a good way for users to reset/wipe it. It's something I think the 
> UEFI Forum ought to put in the standard and require it.

Anaconda does this somehow, I think.  Even just exposing that would be nice.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy  wrote:
>
> On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski  wrote:
>>>
>>> Create a boot menu entry can be skipped if it's not a dual boot system. 
>>> /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default 
>>> on a system without an NVRAM entry already pointing to shim or grub, and a 
>>> fallback entry is created automagically. With Windows, yeah you probably 
>>> have to do something manually because it probably always boots Windows 
>>> otherwise.
>>>
>>
>> Not on my crappy motherboard :(  It apparently can't boot from
>> EFI/BOOT on a hard disk.  Sigh.
>
> Huh, you're sure? You have to either remove all removable NVRAM boot entries, 
> or you have to remove the file/device the entry points to trigger the use of 
> //BOOT/BOOT.efi. If this isn't working, what does happen instead? It 
> just hangs?

Hmm.  I assumed that just asking the system to boot off that disk
would do the trick.  Apparently not.

Removing other entries is hard, given the aforementioned OOPS. :(

>
>>
>> I tried to clarify it a bit, though.
>>
>>>
>>>
>>>>>> It's currently mostly working, modulo the efibootbgr issue.  But I
>>>>>> don't actually know what to type into efibootmgr to fix it, the OOPS
>>>>>> notwithstanding.  I can probably figure it out once the OOPS is fixed.
>>>>>
>>>>> Strictly speaking you don't need to point  UEFI non-Secure Boot computer 
>>>>> to shim.efi, you can just leave it alone and put a grub.cfg in the proper 
>>>>> place. At the grub prompt if you type set you should see either 
>>>>> config_directory= and prefix= to show where it's looking for the grub.cfg.
>>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=73761
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1085957
>>>
>>> I'm not familiar with this usage: efibootmgr -B -b 0
>>>
>>> If 0 is the same as  then that seems to ask for the removal of a fixed 
>>> entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. 
>>> But then it also shouldn't crash the kernel.
>>>
>>> A valid command would be efibootmgr -b 0003 -B
>>>
>>
>> -B -b 0 seems to be the same as -B -b , and my  isn't the same
>> as your  :)
>
> I'm basing it off the  entry in your bug 73761. It points to a DVD drive.
>
>
>>> Something that properly deals with restoring shim, grub, grub.cfg, and 
>>> NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some 
>>> of the manufacturer NVRAM behaviors are pretty icky. And on top of that 
>>> don't seem to have a good way for users to reset/wipe it. It's something I 
>>> think the UEFI Forum ought to put in the standard and require it.
>>
>> Anaconda does this somehow, I think.  Even just exposing that would be nice.
>
> No all it does is look for a Fedora boot entry in NVRAM and then uses 
> efibootmgr -b  -B against it. It doesn't have a mechanism, nor should it, 
> to obliterate everything in NVRAM which can contain a lot more than just boot 
> entries.
>
> ls -l /sys/firmware/efi/efivars
>
> Two dozen variables. On my Mac there's 50+ items including speaker and 
> brightness level.
>

I meant that I assumed that anaconda set up a new boot manager entry.
If it doesn't, and just relies on fallback, then I guess there's
nothing to ask for.

Of course, that'll change once anaconda becomes sensible enough to set
up each ESP once and keep it unmounted from then on, since that'll
involve changing the RPMs so they don't install to /boot/efi.

Unless, of course, /boot/efi just becomes the efi boot template, in
which case some script will need to propagate the contents.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  wrote:
>
> Am 15.04.2014 16:28, schrieb Christian Schaller:
>
>> There was a long thread about this on the desktop mailing list, and I was
>> not in the 'disable the firewall' camp in that discussion, but nobody in
>> that thread or here have articulated how the firewall exactly enhance 
>> security
>> in the situation where we at the same time need to allow each user to have 
>> any
>> port they desire opened for traffic to make sure things like DLNA or 
>> Chromecast
>> works.
>
> that is pretty easy - defaults have to be closed anything and the user
> have to make a choice for, otherwise if there are cirtical security
> updates after a release you have *exactly* the same as WinXP SP2

WinXP SP2 needed a firewall because MS didn't want to close ports 139
and 445 for real.  So instead they hacked it up with a firewall.  This
meant that, if you had the firewall blocking those ports, you were
okay, but if they were open (e.g. because you were at home), you were
screwed.

This is *not* a good thing.

Can someone explain what threat is effectively mitigated by a firewall
on a workstation machine?  Here are some bad answers:

 - Being pwned via MS's notoriously insecure SMB stack?  Not actually
a problem for Fedora.

 - WebRTC, VOIP, etc. issues?  These use NAT traversal techniques that
are specifically designed to prevent your firewall from operating as
intended.

 - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
for these things to be off until specifically requested?  Who actually
uses a so-called "zone" UI correctly to configure them?  How about
having an API where things like DLNA can simply not run until you're
connected to your home network?

Also, having a firewall on exposes you to a huge attack surface in
iptables, and it doesn't protect against attacks targeting the
kernel's IP stack.

I'm all for "secure by default", but I'm not at all convinced that
current desktop firewalls add any real security.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rpcbind is enabled by default, and gnome-boxes requires it

[Andrew Lutomirski]

I don't know whether this should be a gnome-boxes bug, an rpcbind bug,
or a FESCo ticket, or something else, so I'm asking here.

rpcbind enables itself by default.  This page says that it has a
specific exception, so it's okay:

https://fedoraproject.org/wiki/Starting_services_by_default

I assume that the exception comes from the idea that server systems
probably want it on if they've installed it.  That may make sense in
some contexts.

Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which
requires nfs-utils, and nfs-utils requires rpcbind.

gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this:

tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN  774/rpcbind
tcp0  0 0.0.0.0:20048   0.0.0.0:*
LISTEN  887/rpc.mountd
tcp0  0 0.0.0.0:875 0.0.0.0:*
LISTEN  930/rpc.rquotad

*on my laptop*

IMO this is bad.  Should I file a FESCo ticket asking to revoke the
rpcbind and nfs-utils exceptions?  Should I file a bug against
libvirt?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 9:04 AM, Christopher  wrote:
> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski  wrote:
>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  
>> wrote:
>>>
>>> Am 15.04.2014 16:28, schrieb Christian Schaller:
>>>
>>>> There was a long thread about this on the desktop mailing list, and I was
>>>> not in the 'disable the firewall' camp in that discussion, but nobody in
>>>> that thread or here have articulated how the firewall exactly enhance 
>>>> security
>>>> in the situation where we at the same time need to allow each user to have 
>>>> any
>>>> port they desire opened for traffic to make sure things like DLNA or 
>>>> Chromecast
>>>> works.
>>>
>>> that is pretty easy - defaults have to be closed anything and the user
>>> have to make a choice for, otherwise if there are cirtical security
>>> updates after a release you have *exactly* the same as WinXP SP2
>>
>> WinXP SP2 needed a firewall because MS didn't want to close ports 139
>> and 445 for real.  So instead they hacked it up with a firewall.  This
>> meant that, if you had the firewall blocking those ports, you were
>> okay, but if they were open (e.g. because you were at home), you were
>> screwed.
>>
>> This is *not* a good thing.
>>
>> Can someone explain what threat is effectively mitigated by a firewall
>> on a workstation machine?  Here are some bad answers:
>>
>>  - Being pwned via MS's notoriously insecure SMB stack?  Not actually
>> a problem for Fedora.
>>
>>  - WebRTC, VOIP, etc. issues?  These use NAT traversal techniques that
>> are specifically designed to prevent your firewall from operating as
>> intended.
>>
>>  - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
>> for these things to be off until specifically requested?  Who actually
>> uses a so-called "zone" UI correctly to configure them?  How about
>> having an API where things like DLNA can simply not run until you're
>> connected to your home network?
>>
>> Also, having a firewall on exposes you to a huge attack surface in
>> iptables, and it doesn't protect against attacks targeting the
>> kernel's IP stack.
>>
>> I'm all for "secure by default", but I'm not at all convinced that
>> current desktop firewalls add any real security.
>
> Ideally, users would have complete knowledge of the behavior of every
> piece of software in their system that utilizes the network, in which
> case, they could very easily get by without a firewall. However, that
> is not a reasonable expectation. A firewall protects users with
> incomplete knowledge of their software.
>
> Example: user installs software X... but oops, they didn't realize it
> was going to listen on port Y but that's okay, because no firewall
> rule has been enabled to allow traffic on port Y, so the user is
> secure.
>

This sounds like a problem that should be separately fixed.  Even in
the current state of affairs, either software X doesn't support
firewalld, in which case we have the problem that caused this change
request in the first place, or it does support firewalld, in which
case it's unlikely that there will be a benefit.

> Even worse: user installs software X, but which has no network
> features so the user feels safe, but oops, it depends on system
> service Y, which does open network ports, was previously disabled, but
> is now turned on by software X. Firewalls protect against this sort of
> incomplete user knowledge. What if software Y only enables the network
> periodically, to perform some maintenance function? Even a pedantic
> user checking netstat isn't necessarily going to notice network
> services listening on ports periodically.

Arguably this should also be fixed by cleaning up all those network services.

With firewalls, a service, system or otherwise, can be in one of three
states: a) listening w/ firewall open, b) listening w/ firewall
closed, c) and not listening.

c is secure regardless.  a is equally secure regardless.  b is IMO
just broken.  Yes, a firewall can work around case b, at the cost of a
lot of UI hassles and incomprehensible failures, but I think it's a
crappy solution.

I keep thinking that, if I had unlimited time, I'd write a totally
different kind of firewall.  It would allow some policy (userspace
daemon or rules loaded into the kernel) to determine when programs can
listen on what sockets and when connections can be accepted on those
sockets.  This avoids the attack surface of iptables, it will be

Re: rpcbind is enabled by default, and gnome-boxes requires it

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce  wrote:
> On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote:
>> I don't know whether this should be a gnome-boxes bug, an rpcbind bug,
>> or a FESCo ticket, or something else, so I'm asking here.
>>
>> rpcbind enables itself by default.  This page says that it has a
>> specific exception, so it's okay:
>>
>> https://fedoraproject.org/wiki/Starting_services_by_default
>>
>> I assume that the exception comes from the idea that server systems
>> probably want it on if they've installed it.  That may make sense in
>> some contexts.
>>
>> Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which
>> requires nfs-utils, and nfs-utils requires rpcbind.
>>
>> gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this:
>>
>> tcp0  0 0.0.0.0:111 0.0.0.0:*
>> LISTEN  774/rpcbind
>> tcp0  0 0.0.0.0:20048   0.0.0.0:*
>> LISTEN  887/rpc.mountd
>> tcp0  0 0.0.0.0:875 0.0.0.0:*
>> LISTEN  930/rpc.rquotad
>>
>> *on my laptop*
>>
>> IMO this is bad.  Should I file a FESCo ticket asking to revoke the
>> rpcbind and nfs-utils exceptions?  Should I file a bug against
>> libvirt?
>
> Shouldn't rpcbind be simply a dependency for
> nfs-server.service/nfs-secure-server.service and be started only if the
> nfs server is started ?
>

rpcbind has this script:

postinstall scriptlet (using /bin/sh):
if [ $1 -eq 1 ] ; then
# Initial installation
/bin/systemctl enable rpcbind.service >/dev/null 2>&1 || :
fi

nfs-utils has this script (excerpted):

postinstall scriptlet (using /bin/sh):
if [ $1 -eq 1 ]; then
# Package install,
/bin/systemctl enable nfs.target >/dev/null 2>&1 || :
/bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
/bin/systemctl start nfs-lock.service >/dev/null 2>&1 || :

nfs-utils is also pulled in by libvirt.

Why is nfs special enough to deserve this kind of automatic
enablement?  I would argue that nfs requires so much manual
configuration in order to do anything useful that requiring admins to
turn it on would be just fine.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 9:44 AM, Reindl Harald  wrote:
>
>
> Am 15.04.2014 17:40, schrieb Andrew Lutomirski:
>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  
>> wrote:
>
>
>> How about having an API where things like DLNA can simply
>> not run until you're connected to your home network?
>
> you can prove that this will always happen the right way?
> you can implement software *for sure* knowing the fact
> what my home network is? if you can do that you get rich!
>

Does the firewall really help?  Why should you trust your home network
anyway?  Your already-known-to-be-malicious television can mess with
ARP or DHCP, intercept an HTTP request, and CSRF the crap running on
your computer.

Note that there are two separate issues there.  Your home network is
*not* secure, and your firewall, even in fully locked-down mode, isn't
really protecting you.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rpcbind is enabled by default, and gnome-boxes requires it

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 9:25 AM, Simo Sorce  wrote:
> On Tue, 2014-04-15 at 09:16 -0700, Andrew Lutomirski wrote:
>> On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce  wrote:
>> > On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote:
>> >> I don't know whether this should be a gnome-boxes bug, an rpcbind bug,
>> >> or a FESCo ticket, or something else, so I'm asking here.
>> >>
>> >> rpcbind enables itself by default.  This page says that it has a
>> >> specific exception, so it's okay:
>> >>
>> >> https://fedoraproject.org/wiki/Starting_services_by_default
>> >>
>> >> I assume that the exception comes from the idea that server systems
>> >> probably want it on if they've installed it.  That may make sense in
>> >> some contexts.
>> >>
>> >> Alas, libvirt-daemon-kvm requires libvirt-daemon-driver-storage, which
>> >> requires nfs-utils, and nfs-utils requires rpcbind.
>> >>
>> >> gnome-boxes, in turn, requires libvirt-daemon-kvm, resulting in this:
>> >>
>> >> tcp0  0 0.0.0.0:111 0.0.0.0:*
>> >> LISTEN  774/rpcbind
>> >> tcp0  0 0.0.0.0:20048   0.0.0.0:*
>> >> LISTEN  887/rpc.mountd
>> >> tcp0  0 0.0.0.0:875 0.0.0.0:*
>> >> LISTEN  930/rpc.rquotad
>> >>
>> >> *on my laptop*
>> >>
>> >> IMO this is bad.  Should I file a FESCo ticket asking to revoke the
>> >> rpcbind and nfs-utils exceptions?  Should I file a bug against
>> >> libvirt?
>> >
>> > Shouldn't rpcbind be simply a dependency for
>> > nfs-server.service/nfs-secure-server.service and be started only if the
>> > nfs server is started ?
>> >
>>
>> rpcbind has this script:
>>
>> postinstall scriptlet (using /bin/sh):
>> if [ $1 -eq 1 ] ; then
>> # Initial installation
>> /bin/systemctl enable rpcbind.service >/dev/null 2>&1 || :
>> fi
>>
>> nfs-utils has this script (excerpted):
>>
>> postinstall scriptlet (using /bin/sh):
>> if [ $1 -eq 1 ]; then
>> # Package install,
>> /bin/systemctl enable nfs.target >/dev/null 2>&1 || :
>> /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
>> /bin/systemctl start nfs-lock.service >/dev/null 2>&1 || :
>>
>> nfs-utils is also pulled in by libvirt.
>>
>> Why is nfs special enough to deserve this kind of automatic
>> enablement?  I would argue that nfs requires so much manual
>> configuration in order to do anything useful that requiring admins to
>> turn it on would be just fine.
>
> Probably remnants of a past where we did not have dependencies on sysv.
>
> I do not think these rules make sense anymore.

Let's try this without involving FESCo:

https://bugzilla.redhat.com/show_bug.cgi?id=1087950
https://bugzilla.redhat.com/show_bug.cgi?id=1087951

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Andrew Lutomirski]

On Tue, Apr 15, 2014 at 10:00 AM, Reindl Harald  wrote:
>
>
> Am 15.04.2014 18:51, schrieb Andrew Lutomirski:
>> On Tue, Apr 15, 2014 at 9:44 AM, Reindl Harald  
>> wrote:
>>>
>>>
>>> Am 15.04.2014 17:40, schrieb Andrew Lutomirski:
>>>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  
>>>> wrote:
>>>
>>>
>>>> How about having an API where things like DLNA can simply
>>>> not run until you're connected to your home network?
>>>
>>> you can prove that this will always happen the right way?
>>> you can implement software *for sure* knowing the fact
>>> what my home network is? if you can do that you get rich!
>>
>> Does the firewall really help?
>
> yes, because there is no single port reachable after the
> installation and you can at least install security updates
> released after the GA of the current Fedora setup until
> you have a port open

This is true even without the firewall.  I'd argue that one of the
Workstation release requirements should be that a default installation
opens no ports to the outside world.

>> Your already-known-to-be-malicious television can mess with
>> ARP or DHCP, intercept an HTTP request, and CSRF the crap
>> running on your computer.
>
> my television can do a CRSF?

If you browse to a page served by your television, it can certainly
send you a CSRF payload.  Whether or not it works depends on whether
any services running on your box are vulnerable.

> my television can send me a mail and click on a link there?

Probably.

But it can certainly hijack any HTTP request you send and replace the contents.

>
> don't talk about things which are *obviously* out of your business
> http://en.wikipedia.org/wiki/Cross-site_request_forgery
>
> and no my television can do nothing because my television is blocked
> on any incoming port on my computer - guess by what: the firewall

Which doesn't matter *at all*, because it's attacking your *outgoing* traffic.

If you have a firewall between your television and the rest of your
network, you win.  But Fedora can't help you with that, no matter what
its default policy is.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reinstalling the bootloader

[Andrew Lutomirski]

On Mon, Apr 14, 2014 at 4:22 PM, Chris Murphy  wrote:
>
> No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, 
> and 12.3.1.3 "This directory contains EFI images that aide in recovery if the 
> boot selections for the software installed on the EFI system partition are 
> ever lost."

That's a little unfortunate if you have a used motherboard.  Oh, well.

Anyway, as far as I can tell, the newly updated wiki page should be helpful now.

>
>> Removing other entries is hard, given the aforementioned OOPS. :(
>
> Sure. OOPS isn't good. But chances are it's naughty firmware.
>
>

I'm sure it is. :)

>> Of course, that'll change once anaconda becomes sensible enough to set
>> up each ESP once and keep it unmounted from then on, since that'll
>> involve changing the RPMs so they don't install to /boot/efi.
>
> Has there been buy off on this?

No clue.

I suspect it would be easy to implement by anyone who understands GRUB
2 syntax.  That's not me, alas.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Andrew Lutomirski]

On Wed, Apr 16, 2014 at 3:58 PM, Matthew Miller
 wrote:
> On Thu, Apr 17, 2014 at 12:55:31AM +0200, Lars Seipel wrote:
>> > > Perhaps shorten to:
>> > > block
>> > > public
>> > > work
>> > > home
>> > That is a much more intuitive default set.
>> Is it? What's supposed to be the difference between work and home?
>
> I don't know if it's intuitive or not, but I can imagine that I might want
> to share music to my home network by default but wouldn't want that to
> happen at work.

For that matter, what's the difference between "public" and "block"?

This has always bugged me about Windows 7's firewall.  I never know
what to click, because I have no idea what the options do.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: When a yum update sets up an MTA ...

[Andrew Lutomirski]

On Sun, Apr 20, 2014 at 6:39 PM, Lars Seipel  wrote:
> Nicely aligning with the current firewall thread I noticed that one of
> my machines was running the exim MTA for the last few days, dutifully
> listening on all interfaces.
>
> How did this happen? It turns out that smartmontools intermittently
> required 'MTA' which (presumably due to its nice and short name) pulls
> in exim when there's no MTA already installed. This dependency was
> replaced (with a file dep on %{_sbindir}/sendmail) in
> smartmontools-6.2-5.fc20.
>
> Ok, that's how it got installed. But why does it get run? Is the
> installation of exim tricking my system into believing it's Debian?
>
> We do have the presets functionality[0] for this, I thought. And indeed,
> a call to systemctl preset disables exim.service just like it's supposed
> to do.
>
> Looking at exim's spec file shows its %post is using the proper
> systemd_post macro which honors presets. In %postun, though, there's a
> direct call to systemctl enable, buried in the sysv conversion stuff. Is
> it really supposed to be there? But this shouldn't get executed on
> package install anyway, right?
>
> Would be glad if someone who knows a bit more about the interaction of
> RPM and systemd preset files could chime in and tell me where the bug
> report should go.

I think it's because upgrading installs a new package and uninstalls
an old package.  Sounds like a bug in exim.

So far, I know that this issue exists, in some form, in rpcbind,
nfs-utils, and exim.  Would it
make sense to audit all spec files to look for instances of
'systemctl.*enable'?  If so, is there an easy way to grab all the spec
files?  Scraping pkgs.fedoraproject.org is a bit painful.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: When a yum update sets up an MTA ...

[Andrew Lutomirski]

On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer  wrote:
> On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
>>
>> Would it
>> make sense to audit all spec files to look for instances of
>> 'systemctl.*enable'?
>
>
> I'm attaching the hits for that pattern on the actual RPM scripts in Fedora
> rawhide (x86_64).  This combines both regular scripts and trigger scripts.
> I can add additional columns with more information, but the text file will
> become a bit unwieldy.

Time to file a bunch of bugs?  I can do it, but if someone has
scripts, that could help.

Are there any currently supported upgrade paths from sysv to systemd
for any of these services?  If F19 already had all of these, then it
may make sense to just remove the migration code.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

Hi all-

I propose a mass bug against packages that install services and enable
them without using the preset mechanism.  Some of these can be
security issues if they get installed as dependencies.

As a related issue, it may pay to review the default presets.  For
example, rpcbind is enabled.  This seems bad.

I know of three of these bugs that already exist:

https://bugzilla.redhat.com/show_bug.cgi?id=1089650
https://bugzilla.redhat.com/show_bug.cgi?id=1087951
https://bugzilla.redhat.com/show_bug.cgi?id=1087950

The text would be:

--- cut here ---
A number of packages install systemd units and enable them
automatically.  They should not.  Please update the package to use the
macroized scriptlet
(https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).

If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.

Given that this issue can affect Fedora 20 users who install your
package as a dependency, these bugs should be fixed in Fedora 20 and
Rawhide.

The affected packages are:

OpenIPMI
at
avahi
avahi-dnsconfd
bcfg2
bcfg2-server
bwbar
cronie
deltacloud-core
device-mapper-multipath
dmapd
exim
fsniper
gpm
groonga
hsqldb
iscsi-initiator-utils
jabberd
libvirt
libvirt-client
lvm2
mailman
mdadm
monit
openct
opendkim
openssh-server
partimage
rhnsd
rinetd
rpcbind
sendmail
varnish
vdsm
xrdp
yum-cron
yum-updatesd

--- cut here ---
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Tue, Apr 22, 2014 at 12:00 PM, Miloslav Trmač  wrote:
> Hello,
> 2014-04-22 20:50 GMT+02:00 Andrew Lutomirski :
>
>> If your package has an exception from FESCo permitting it to enable
>> itself,
>
>
> Note that many (most?) packages don't need an individual exception by FESCo:
> https://fedoraproject.org/wiki/Starting_services_by_default allows fairly
> wide categories.
>  Mirek

Hmm. I can't actually find anything in that category in the list here
except, sort of, OpenIPMI.  OpenIPMI seems rather confused -- it has a
systemd service that claims to be oneshot but still has a stop
command.  That service does one-shot stuff and (I think) starts a real
daemon.  It should probably be split into two units.  In any event,
the actual offending code in OpenIPMI is in %triggerun, so it should
still go, and I think OpenIPMI has a preset entry anyway.

Nonetheless, I'll add:

If your package falls into the general exception, then it is possible
that no change is required.  Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible.  The
exception is:

In addition, any service which does not remain persistent on the
system (aka, it "runs once then goes away"), does not listen to
incoming connections during initialization, and does not require
configuration to be functional may be enabled by default (but is not
required to do so). Examples of "runs once then goes away" services
include iptables and udev.

Also, yum-cron and varnish should be removed from the list.  Varnish
doesn't actually auto-enable itself, and yum-cron is dead.

>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Tue, Apr 22, 2014 at 2:19 PM, "Jóhann B. Guðmundsson"
 wrote:
>
> On 04/22/2014 06:50 PM, Andrew Lutomirski wrote:
>>
>> Hi all-
>>
>> I propose a mass bug against packages that install services and enable
>> them without using the preset mechanism.  Some of these can be
>> security issues if they get installed as dependencies.
>
>
> I will revisit all of this once I run the systemd cleanup process

What's that?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Tue, Apr 22, 2014 at 2:54 PM, "Jóhann B. Guðmundsson"
 wrote:
>
> On 04/22/2014 09:32 PM, Andrew Lutomirski wrote:
>>
>> On Tue, Apr 22, 2014 at 2:19 PM, "Jóhann B. Guðmundsson"
>>   wrote:
>>>
>>> >
>>> >On 04/22/2014 06:50 PM, Andrew Lutomirski wrote:
>>>>
>>>> >>
>>>> >>Hi all-
>>>> >>
>>>> >>I propose a mass bug against packages that install services and enable
>>>> >>them without using the preset mechanism.  Some of these can be
>>>> >>security issues if they get installed as dependencies.
>>>
>>> >
>>> >
>>> >I will revisit all of this once I run the systemd cleanup process
>>
>> What's that?
>
>
> Just a various stuff ( todo list ) that I know that needs to be performed
> once I have finished the legacy sysv to systemd migration in the
> distribution, to better integrate systemd in Fedora
> core/baseOS/containers/servers and what not.
>
> In that process I will be revisiting all components shipping unit files and
> depend on systemd amongst other things.
>
> Once that process is done ( ca 1000 - 1500 hours of work by my gestimation )
> I will declare the init system replacement officially done.
>

I don't think that fixing the broken packages should need to wait for
this migration to finish -- there is a security problem now, and it
can be fixed now with local changes to the thirty-something affected
packages.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Tue, Apr 22, 2014 at 3:14 PM, "Jóhann B. Guðmundsson"
 wrote:
>
> On 04/22/2014 10:14 PM, Andrew Lutomirski wrote:
>>
>> I don't think that fixing the broken packages should need to wait for
>> this migration to finish -- there is a security problem now, and it
>> can be fixed now with local changes to the thirty-something affected
>> packages.
>
>
> By all means provide patches and fix those packages if you think this is
> such a urgent matter.

This thread is about getting consensus for a mass bug filing.  Can I
take this as your agreement?

Patches can come later.  For the most part, they'll be trivial -- the
specfiles can just switch to using the standard systemd scriptlets.

>
>
> JBG
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Tue, Apr 22, 2014 at 7:02 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Apr 22, 2014 at 12:17:10PM -0700, Andrew Lutomirski wrote:
>> Examples of "runs once then goes away" services
>> include iptables and udev.
> I removed udev from this paragraph on the wiki, since it's persistent and
> is a bad example.

Thanks :)

If no one tells me otherwise today, I will take the lack of objections
to the mass bug filing as consensus.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mass bug proposal: packages that auto-enable systemd units

[Andrew Lutomirski]

On Wed, Apr 23, 2014 at 9:06 AM, Kevin Fenzi  wrote:
> On Wed, 23 Apr 2014 08:49:58 -0700
> Andrew Lutomirski  wrote:
>
>> On Tue, Apr 22, 2014 at 7:02 PM, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> > On Tue, Apr 22, 2014 at 12:17:10PM -0700, Andrew Lutomirski wrote:
>> >> Examples of "runs once then goes away" services
>> >> include iptables and udev.
>> > I removed udev from this paragraph on the wiki, since it's
>> > persistent and is a bad example.
>>
>> Thanks :)
>>
>> If no one tells me otherwise today, I will take the lack of objections
>> to the mass bug filing as consensus.
>
> It seems like it might be workable to have a provenpackager fix up any
> of these not fixed in a few weeks...
>
> If you would like to add to the text that after 3 weeks provenpackagers
> may step in and fix these issues, that might be good? Or is there some
> reason that wouldn't be a good idea?

As long as the provenpackager is wiling to double-check that the
change is correct, it sounds good to me.

Most of these seem like copies of a buggy sysv conversion script and
don't even happen on initial installation, so it seems very unlikely
that important package functionality depends on the scripts running.

--Andy

>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: When a yum update sets up an MTA ...

[Andrew Lutomirski]

On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer  wrote:
> On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
>>
>> Would it
>> make sense to audit all spec files to look for instances of
>> 'systemctl.*enable'?
>
>
> I'm attaching the hits for that pattern on the actual RPM scripts in Fedora
> rawhide (x86_64).  This combines both regular scripts and trigger scripts.
> I can add additional columns with more information, but the text file will
> become a bit unwieldy.

Can you double-check this?  nfs-utils isn't in this list, but I think
it should be.

Also, how did you generate this?

Thanks,
Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Mass bug: packages should not auto-enable systemd units

[Andrew Lutomirski]

Hi everyone-

This is a notice in accordance with the mass bug filing procedure.

A number of packages install systemd units and enable them
automatically.  They should not.  Please update these packages to use the
macroized scriptlet
(https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).

If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.

There is a general exception described here:

https://fedoraproject.org/wiki/Starting_services_by_default

If your package falls under the general exception, then it is possible
that no change is required.  Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible.  The
exception is:

In addition, any service which does not remain persistent on the
system (aka, it "runs once then goes away"), does not listen to
incoming connections during initialization, and does not require
configuration to be functional may be enabled by default (but is not
required to do so). An example of "runs once then goes away" service
is iptables.

Given that this issue can affect Fedora 20 users who install your
package as a dependency, these bugs should be fixed in Fedora 20 and
Rawhide.

The tracker bug is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1090684

I created it early because three of the bugs are pre-existing.  Next
week, I'll file bugs against the packages below.  If you fix your
package in the mean time, please let me know.

After three weeks, provenpackagers may step in and fix these issues.

OpenIPMI
at
avahi
avahi-dnsconfd
bcfg2
bcfg2-server
bwbar
cronie
deltacloud-core
device-mapper-multipath
dmapd
fsniper
gpm
groonga
hsqldb
iscsi-initiator-utils
jabberd
libvirt
libvirt-client
lvm2
mailman
mdadm
monit
openct
opendkim
openssh-server
partimage
rhnsd
rinetd
sendmail
vdsm
xrdp
yum-updatesd

It's possible that I'm missing some packages.  I may follow up with an
updated list.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: When a yum update sets up an MTA ...

[Andrew Lutomirski]

On Thu, Apr 24, 2014 at 2:00 AM, Florian Weimer  wrote:
> On 04/24/2014 01:57 AM, Andrew Lutomirski wrote:
>>
>> On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer 
>> wrote:
>>>
>>> On 04/21/2014 03:44 AM, Andrew Lutomirski wrote:
>>>>
>>>>
>>>> Would it
>>>> make sense to audit all spec files to look for instances of
>>>> 'systemctl.*enable'?
>>>
>>>
>>>
>>> I'm attaching the hits for that pattern on the actual RPM scripts in
>>> Fedora
>>> rawhide (x86_64).  This combines both regular scripts and trigger
>>> scripts.
>>> I can add additional columns with more information, but the text file
>>> will
>>> become a bit unwieldy.
>>
>>
>> Can you double-check this?  nfs-utils isn't in this list, but I think
>> it should be.
>
>
> I accidentally used systemd.*enable as the pattern.  The attached list was
> created using systemctl[^\n]*enable instead.
>
>
>> Also, how did you generate this?
>
>
> I've got a tool which extracts interesting data from RPMs (metadata, but
> also Java method references, ELF symbols, Python imports).  I've added the
> query I used as an example here:
>
>
> <https://github.com/fweimer/symboldb/blob/master/doc/examples/rpm-scripts.txt>
>

Want to help with further analysis?  Setting up symboldb looks like a
lot of work.

The issues so are are:

1. It turns out that a lot of the %triggerun things are okay -- they
only run on upgrade from very old package versions.  But postinstall
is a problem, e.g. nfs-utils
2. I think you have data from RPMs that are retired, e.g. yum-cron.
3. The exim issue was caused by the --initscript option to
alternatives.  It would probably make sense to remove that option
entirely, but it could also be good to find and fix everything that
uses it.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS failover solution needed, nscd?

[Andrew Lutomirski]

On Fri, Apr 25, 2014 at 3:51 PM, Chuck Anderson  wrote:
> I'm starting a new thread to clarify and emphasize the problem I'm
> actually trying to solve.  Here is the problem restated as I posted it
> to the dns-operations list:
>
> -
> Is it really expected that the first DNS server listed in
> /etc/resolv.conf should never go down?  Operationally speaking, who
> can actually rely on listing multiple nameservers in /etc/resolv.conf
> and using libc's failover mechanism in any kind of production server?
> Because the failover behavior in libc is atrocious--each new or
> existing process has to re-do the failover after timing out, and even
> long-running processes have to call res_init() to re-read resolv.conf.
> It seems that the only sensible way to run a datacenter (or a network
> full of Linux workstations for that matter) is to either:
>
> 1. Make sure the first nameserver listed in resolv.conf never goes
>down by using Anycast DNS or some other failover mechanism like
>VRRP or CARP on the DNS server side.

Unworkable on normal servers or for normal home users.

>
> or:
>
> 2. Use a local DNS daemon on every server with forwarders configured
>to the network's nameservers, and fix resolv.conf to 127.0.0.1.
> -
>
> (I've since learned that nscd can be a third option)

>
>> >nscd is ... bad
>
> I've since learned more about nscd.  Apparently its reputation may be
> undeserved, at least the newer versions in glibc.  I have no direct
> experience, but I finally found a good thread about fixing the stub
> resolver that addresses people's unwillingness to use nscd as well as
> some other things that could be done, such as a patch apparently
> carried by Debian and Ubuntu that improves detection of changes to
> resolv.conf:
>
> https://sourceware.org/ml/libc-alpha/2012-12/msg00416.html

I've never understood why something like nscd is even worth trying to
support.  There's a simple, well specified protocol that program can
use to talk to a DNS resolver.  It's called DNS.  Why try to shoehorn
it into something else when all you're likely to do is come up with a
poor imitation of what you get by sending DNS queries over DNS to a
local resolver?

I'm sure it would be possible to improve/rewrite nscd, but at
best you'll match the quality of something like unbound.  And you'll
never be compatible with all the third-party resolver clients out
there.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Tue, Apr 29, 2014 at 8:18 AM, Chuck Anderson  wrote:
> On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote:
>> On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
>> > = Proposed System Wide Change:  Default Local DNS Resolver =
>> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>> >
>> > Change owner(s): P J P , Pavel Šimerda
>> > , Tomas Hozza 
>> >
>> > To install a local DNS resolver trusted for the DNSSEC validation running 
>> > on
>> > 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
>>
>> This is gonna conflict a bit with docker, and other  users of network
>> namespaces, like systemd-nspawn. When docker runs, it picks up the
>> current /etc/resolv.conf and puts it in the container, but the container
>> itself runs in a network namespace, so it gets its own loopback device.
>> This will mean 127.0.0.1:53 points to the container itself, not the
>> host, so dns resolving in the container will not work.
>>
>> Not sure how to fix something like that though...
>
> Is it possible to use a different loopback device like 127.0.0.53 and
> then have that point outside the container somehow?

I like this solution, although I think it'll require making unbound
bind to 127.0.0.53 for the non-container case, too.

OTOH, it would be straightforward to write a tiny stub that forwards
127.0.0.1:53 to something outside the container.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct