Re: Bodhi-Problem? -> Firefox 32 / Thunderbird 31.1
There are currently "208 Pending Updates" https://admin.fedoraproject.org/updates/F20/pending On the left column it shows 112 pending updates. I have never seen it go down to zero? On Sun, Sep 7, 2014 at 11:34 AM, Kevin Fenzi wrote: > On Sun, 07 Sep 2014 20:24:58 +0200 > Reindl Harald wrote: > >> >> >> Am 07.09.2014 um 20:17 schrieb Kevin Fenzi: >> > On Sun, 07 Sep 2014 20:06:03 +0200 >> > Reindl Harald wrote: >> >> >> >> Am 07.09.2014 um 19:55 schrieb drago01: >> >>> On Sun, Sep 7, 2014 at 7:53 PM, Reindl Harald >> >>> wrote: >> there must be something wrong in the infrastructure >> >> * the update has more than enough karma >> * it's even not visible in updates-testing >> >> https://admin.fedoraproject.org/updates/firefox-32.0-1.fc20,xulrunner-32.0-1.fc20,thunderbird-lightning-3.3-3.fc20,thunderbird-31.1.0-1.fc20 >> >>> >> >>> So seems like its newer than either F21 and/or rawhide >> >> >> >> maybe >> >> >> >> but somebody should take action, these are security relevant >> >> updates deployed all over the plant including Android except Fedora >> > >> > There's several issues here: >> > >> > 0) The autoqa note above. The maintainer could override that and >> > push to testing. >> > >> > 1) The update got karma to go stable before it was even pushed to >> > testing, so it's not gone into testing. >> > >> > 2) F21 is currently in Alpha freeze. Only updates that fix accepted >> > blockers or freeze exceptions go to stable. As far as I know, this >> > update doesn't. Someone could propose one if they felt strongly >> > about it. Failing that it's not going to go 'stable' until after >> > Alpha is go >> >> that's a Fedora 20 update and not relevant for F21 Alpha freeze > > Indeed. I misread. ;) > > But the reason for the autoqa failure was that the f21 update wasn't > pushed due to freeze. > > In any case, the maintainer can submit to stable or testing as they > like. > > 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: f21 Mass rebuild, freeze, and other status
On Wed, Aug 20, 2014 at 4:27 PM, Kevin Fenzi wrote: > The recent mass rebuild for glibc/gcc fixes finished monday. However, > it was discovered that there was a rpm bug present for the last ~1300 or > so builds in the mass rebuild. This bug would cause packages that > override provides/requires to just not add their requires at all. > https://bugzilla.redhat.com/show_bug.cgi?id=1131892 > I have just finished scraping the logs for those ~1300 f21 builds and > identified the packages affected. I will be rebuilding them in f21 and > rawhide. Happily it isn't too many packages. Packages outside of the > mass rebuild may also be affected, maintainers are advised to > doublecheck their build.log if they override provides/requires and > built anything the last few days. > > 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 Wouldn't it be better / safer to just to do the mass rebuild all over again for all the packages? I mean what if a package slips through the cracks for the final release? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
No Updates to F20 since August 1st?
Why has there been no updates to F20 since August 1st, 2014? https://admin.fedoraproject.org/updates/F20/ -- 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: /media -> /run/media???
This issue came up recently for me.
I asked this on superuser:
https://superuser.com/questions/775882/what-do-i-have-to-do-so-i-can-get-2-users-to-be-able-to-access-disk-drives-par
What do I have to do so I can get 2 users to be able to access disk
drives / partitions at the same time?
I mounted a disk drive using UserA ==> /run/media/userA/myDisk .
userB is a member of the same group of userA.
Why can userB not access the mountpoints?
What do I have to do so I can get 2 users to be able to access disk
drives / partitions at the same time?
Also to note the disks are encrypted.
I do not want chmod the files or directory to 777
==
I really liked the answer:
udisks2 intentionally makes removable devices private to the user. (By
design, Linux is a multi-user system, and can potentially have several
people having separate seats (displays, keyboards, USB ports) and
connecting their own USB drives, so they should be separate from each
other.) So all per-user directories under /run/media are limited to
their owner only.
To make udisks2 place all mountpoints under /media, which it used to
do in the past, you can install a n udev rule by placing the following
in /etc/udev/rules.d/90-udisks2-shared.rules:
SUBSYSTEM=="block", ENV{UDISKS_FILESYSTEM_SHARED}="1"
Alternatively, you could move a specific device by configuring it in
/etc/fstab, e.g.:
/dev/mapper/luks-backups /mnt/backup auto noauto,nosuid,nodev,nofail,x-gvfs-show
In fact, you should always use /etc/fstab for internal or otherwise fixed disks.
However, this will only allow other users to reach the mountpoint, it
will not automatically allow them to browse files inside – you will
need to change the files' permissions. This depends on the filesystem
your disk is using.
If you use ext4, btrfs, or generally any filesystem that supports Unix
file ownership & permissions, use groupadd to create a dedicated group
for users allowed to access the disk; gpasswd -a to add them to the
group; then mount the disk and chown -R it to the newly created group.
Use chmod -R g+rwX to make all files group-accessible, and find
/mnt/disk -type d -exec chmod g+s {} + to make them inherit the group
ownership.
If you use fat32/vfat, do the same, but changing ownership or
permissions will not work; instead, you will need to add the gid=...
mount option in /etc/fstab. (The option should have the actual ID of
the group that you just added.)
I followed the first step and now I am able to access the mounts from
another user. The location now for me is /media
On Mon, Aug 4, 2014 at 9:30 AM, Lennart Poettering wrote:
> On Mon, 04.08.14 18:13, Marcin Juszkiewicz (mjuszkiew...@redhat.com) wrote:
>
>> Can someone point me to discussion which ended in /media being symlink
>> to /run/media directory?
>>
>> I am now looking at Picasa rescanning 40GB of pictures just because
>> /media/storage/ dissapeared after upgrade of packages (which moved
>> /media/ to /media.rpmmoved/ one).
>>
>> Should I create /my-own-directory-do-not-even-think-about-touching-it/
>> and keep mountpoints of all hard drives there just to hope that it will
>> stay there for next year?
>
> Yes, you should.
>
> /media was supposed to be the place where removable media is
> automatically mounted. There are no rules on how things are named for
> it, not whether the directory names are stable in any way. hal and
> udisks used to mount stuff there, but they haven't done that since quite
> a while now, since removable media should be private to the user, and a
> system-wide namespace is inappropriate for that really. Thus it moved to
> a user-private directory in /run/media/$USER/ instead, which nobody but
> the user who is active on the seat the media was inserted to has access
> to. This fixes a number of security problems since the namespace is
> now private to the user, and a rogue user cannot confuse another user's
> apps by taking possession of the /media path where they'd expect a
> device to show up...
>
> Now, while /run/media (and formerly /media) are under strictly automatic
> control by udisks, the directory hierarchy /mnt is supposed to be under
> admin control. If you want to mount arbitrary stuff to fixed places
> following your own naming scheme, that's where you are supposed to mount
> your stuff. If you want your removable media device to show up there,
> simply edit /etc/fstab and add a line of your choice.
>
> To make this more confusing, to my knowledge Ubuntu (or is it Debian as
> its upstream?) actually patches /run/media/$UID back into /media. Or at
> least I did that. It's stupid, and a security hole, and they should stop
> doing that, but they know better...
>
> The /media directory should probably be dropped from FHS, as it it's
> really pointless, and is nothing one would ever use today. In fact, our
> filesystem.rpm package should really stop shipping that (but then again,
> I mean, it also ships /var/gopher, ...)
>
> Lennart
>
> --
> Lennart Poettering,
Re: Half-OT: Secure boot and thirdy party kernel modules
So did any of you get it to work? That is signing VirtualBox modules and enabling secure boot in the bios? On Tue, Jul 8, 2014 at 6:20 AM, Sergio Belkin wrote: > > > 2014-07-08 5:47 GMT-03:00 Florian Weimer : > >> On 07/08/2014 10:19 AM, Petr Pisar wrote: >>> >>> On 2014-07-07, Florian Weimer wrote: Note that Microsoft's current policy may not allow unrestricted virtualization (KVM or Virtualbox—does not matter) because that "permits launch of another operating system instance after execution of unauthenticated code"—the wording is rather unclear. If Microsoft clarifies that this is forbidden, a future Fedora update will remove this functionality, so you will be forced to disable Secure Boot at this point anyway if you want to continue to use virtualization. >> >> >>> Could you elaborate more what "unauthenticated code" is in this case? >> >> >> I think it's code that is not cryptographically tied (indirectly) to one >> of the Secure Boot trust roots. >> >> However, I don't really know what Microsoft means. It's conceivable that >> they assume we sign all of user space (not just for installation purposes), >> and they might have a wrong idea about what we can implement in our system. >> >> >>> Is >>> it a userspace tool for controlling in-kernel virtualization (e.g. qemu >>> in case of KVM)? Because KVM as a kernel module is signed. >> >> >> It's unclear. One possible interpretation is that virtualization acts as >> a barrier because it does not provide access to "real" ring 0 on the host. >> It sounds reasonable, but it doesn't really match Microsoft's wording I >> quoted above (from a public blog post). >> >> >> -- >> 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 > > > Thanks everybody for enlighten me about this obscure topic :) > > > -- > -- > Sergio Belkin http://www.sergiobelkin.com > LPIC-2 Certified - http://www.lpi.org > > -- > 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: default local DNS caching name server
DNS over SSL does NOT work - I get no connectivity whatsoever after following the below steps. Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=1119050 Can you please tell me what am I doing wrong? @ https://fedoraproject.org/wiki/Test_Day:2012-12-11_Network_Manager_and_DNSSEC it says to do: sudo yum install dnssec-trigger sudo systemctl enable dnssec-triggerd.service sudo systemctl enable unbound.service sudo reboot Then to get DNS over SSL @ https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL it says to do: sudo iptables -A OUTPUT -o lo -j ACCEPT sudo iptables -A OUTPUT -p tcp --dport 53 -j DROP sudo iptables -A OUTPUT -p udp --dport 53 -j DROP Then we are supposed to click on re-probe. And now there is no connectivity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNS over SSL - Is dnssec-trigger supposed to work in F20?
From here: https://fedoraproject.org/wiki/Test_Day:2012-12-11_Network_Manager_and_DNSSEC it says to do: sudo yum install dnssec-trigger sudo systemctl enable dnssec-triggerd.service sudo systemctl enable unbound.service sudo reboot Then to get DNS over SSL it says https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL to do: sudo iptables -A OUTPUT -o lo -j ACCEPT sudo iptables -A OUTPUT -p tcp --dport 53 -j DROP sudo iptables -A OUTPUT -p udp --dport 53 -j DROP Then we are supposed to click on re-probe. -- 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: Need instructions with packaging
The comment is from 2007 Ralf Ertzinger 2007-11-28 06:44:41 EST Apart from the IOS files, the sources contain two binary files (mips64_microcode, ppc32_microcode) which are somehow incorporated into the emulator. I do not know what these files contain or where they come from and what license they are under. GNS3 took over development of dynamips. Are the binary files still there? GNS3 does not provide the IOS images as far as I know. On Sat, May 3, 2014 at 5:39 PM, Christopher Meng wrote: > On Sun, May 4, 2014 at 8:33 AM, Adrian Soliard > wrote: >> Right, that's another dynamips. But, what is the other link I share >> before? It's also dynamips. >> >> What that "CANTFIX" means? Can I get the packaging process of >> dynamips? And how do I do it? > > That means this package has issues which CANNOT be fixed if upstream > doesn't change. > > See comment 6: > > https://bugzilla.redhat.com/show_bug.cgi?id=246150#c6 > -- > 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
[Request] Backport gnome-shell patch for F20 to fix broken screen keyboard during password pop up dialog
[Request] Backport gnome-shell patch for F20 to fix broken screen keyboard during password pop up dialog Can some who has the know how and the appropriate privileges to push the update to F20's gnome-shell 3.10.x backport this patch: https://bugzilla.gnome.org/show_bug.cgi?id=719451 Relevant Redhat Bugzilla: [Bug 1071907] screen keyboard does not work for password pop up dialog -- https://bugzilla.redhat.com/show_bug.cgi?id=1071907 Thanks in advance. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Upstream developer has some questions regarding Gsettings and Dconf
I filed the below bug and the upstream developer has some questions regarding Gsettings and Dconf. If anyone knows the answers to the below questions please email back. Thanks. https://bugzilla.redhat.com/show_bug.cgi?id=1094052 --- Comment #3 from François Agrech --- Hello, I'm the main uptream developer of Florence. Christopher Meng made me aware of this bug, thank you for reporting it. Documentation about dconf and GSettings is sparse but from what I have read here: https://developer.gnome.org/gio/stable/GSettings.html, it looks like is the right root node. I failed to find any documentation about Could you please give me more details? Why do you think it is supposed to be instead of ? How do I make GSettings to handle a root node? What is the specification of this node? Is there a DTD or XSD about it? Could you please point me to the right documentation about ? -- -- 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 Bloat from the next Live CD (Desktop)
How do I go about contacting the "workstation working group"? - Made a mistake in my original post - the package ibus-libs was not supposed to be included. Here is the updated command: sudo yum remove ibus ibus-chewing ibus-gtk2 ibus-gtk3 ibus-hangul ibus-kkc ibus-libpinyin ibus-m17n ibus-rawcode ibus-setup ibus-wayland libchewing libpinyin libpinyin-data opencc lohit-assamese-fonts lohit-bengali-fonts lohit-devanagari-fonts lohit-gujarati-fonts lohit-kannada-fonts lohit-malayalam-fonts lohit-oriya-fonts lohit-punjabi-fonts lohit-tamil-fonts lohit-telugu-fonts jomolhari-fonts vlgothic-fonts cjkuni-uming-fonts wqy-zenhei-fonts thai-scalable-fonts-common thai-scalable-waree-fonts smc-fonts-common smc-meera-fonts sil-abyssinica-fonts sil-mingzat-fonts sil-nuosu-fonts sil-padauk-fonts nhn-nanum-fonts-common nhn-nanum-gothic-fonts paratype-pt-sans-fonts google-noto-sans-lisu-fonts google-noto-sans-mandaic-fonts google-noto-sans-meeteimayek-fonts google-noto-sans-tagalog-fonts google-noto-sans-tai-tham-fonts google-noto-sans-tai-viet-fonts khmeros-base-fonts lklug-fonts paktype-naqsh-fonts tabish-eeyek-fonts Installed size = approx 113 MB I am sure there are more packages that are for international support only (not used by English speaking users) which I have not come across yet. On Sun, May 11, 2014 at 5:35 AM, Bruno Wolff III wrote: > On Sat, May 10, 2014 at 13:49:57 -0700, > quickbooks office wrote: > >> Removing Bloat from the next Live CD (Desktop) : >> >> I have noticed alot of packages are included in the Live CD which are >> not really used by users who only speak English. >> >> I think it really makes sense to split the Live CD into 2 versions. >> >> The default version will be for English only. >> >> The second Live CD (not the default) will be English + international >> languages support. >> > > This is something you'd want to ask the workstation working group. That is > going to replace the live desktop spin. > > However, I doubt they are going to want to do this, as they probably will > value having one version of that product over having two, where one is a > smaller size. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Removing Bloat from the next Live CD (Desktop)
Removing Bloat from the next Live CD (Desktop) : I have noticed alot of packages are included in the Live CD which are not really used by users who only speak English. I think it really makes sense to split the Live CD into 2 versions. The default version will be for English only. The second Live CD (not the default) will be English + international languages support. = Here are the packages which I believe can be removed without any adverse effects: ibus ibus-chewing ibus-gtk2 ibus-gtk3 ibus-hangul ibus-kkc ibus-libpinyin ibus-libs ibus-m17n ibus-rawcode ibus-setup ibus-wayland libchewing libpinyin libpinyin-data opencc lohit-assamese-fonts lohit-bengali-fonts lohit-devanagari-fonts lohit-gujarati-fonts lohit-kannada-fonts lohit-malayalam-fonts lohit-oriya-fonts lohit-punjabi-fonts lohit-tamil-fonts lohit-telugu-fonts jomolhari-fonts vlgothic-fonts cjkuni-uming-fonts wqy-zenhei-fonts thai-scalable-fonts-common thai-scalable-waree-fonts smc-fonts-common smc-meera-fonts sil-abyssinica-fonts sil-mingzat-fonts sil-nuosu-fonts sil-padauk-fonts nhn-nanum-fonts-common nhn-nanum-gothic-fonts paratype-pt-sans-fonts google-noto-sans-lisu-fonts google-noto-sans-mandaic-fonts google-noto-sans-meeteimayek-fonts google-noto-sans-tagalog-fonts google-noto-sans-tai-tham-fonts google-noto-sans-tai-viet-fonts khmeros-base-fonts lklug-fonts paktype-naqsh-fonts tabish-eeyek-fonts If you know a package I may have missed above please let me know. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rawhide users vulnerable to man-in-the-middle attacks?
If the packages in Rawhide are not signed aren't rawhide users vulnerable to man-in-the-middle attacks? Worse it also allows mirrors to send out malicious packages to certain users, as the package will not be checked by the end user? I really think all the packages in Rawhide should be signed before being pushed out the end user. -- 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
On Thu, Apr 10, 2014 at 2:30 AM, Daniel P. Berrange wrote: > On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: >> >> This sounds entirely backwards, and I'd instead vote for removing >> securetty from the PAM stacks we ship altogether. The concept is >> outdated. It was useful in a time where the primary way to access a >> server was via physically attached TTY devices. But that time is mostly >> over... >> >> Nowadays the device names exposed by the kernel tend to be dynamically >> assigned, they should not be assumed stable (with one exeption, classic >> UART 16650 serial ports). Stable paths for these devices we add in via >> symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you >> might know from disk devices. Now, the securetty logic is unable to >> verify things using these symlinks, hence the entire concept is >> flawed. It will use an unsteable device name instead, making it mostly >> useless in hotplug scenarios. >> >> securetty is particularly annoying when we use containers. Tools like >> "machinectl login" will dynamically spawn a getty for you on a pts >> device in the container, but since pts is not listed in securetty you >> cannot log in as root by default. And you cannot event add a wildcard >> match of pts/* to it, to make this work nicely. > > Yep, the securetty file is one of only 2 remaining blockers for getting > login working out of the box in containers. Removing securetty would be a > great help there given the inability to wildcard pts/*. The other problem > is of course the horrible pam audit module, which the kernel guys are > hopefully working towards a solution for. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct --- On Wed, Apr 9, 2014 at 2:50 PM, Matthew Miller wrote: > On Wed, Apr 09, 2014 at 11:39:19PM +0200, Lennart Poettering wrote: >> To clarify this: while I believe dropping securetty from the default PAM >> config is the right thing to do, I am not vulunteering to do it. But I'd >> love to see somebody to pick this up! > > I looked, and I think this is just a change in util-linux package (not the > source even; the pam files are packaged as separate sources) + a note in the > release notes. It's not referenced in authconfig or anything. > > I guess maybe we'd also want to remove /etc/securetty to reduce confusion > (since the normal semantics are that missing file = nothing blocked), that's > in setup. > > But otherwise, I think it just comes down to filing an RFE and getting the > util-linux maintainer on board. Probably best after this change proposal > gets to FESCo -- at that point, I'll put this forward as a counter-proposal. > > -- > Matthew Miller-- Fedora Project-- > "Tepid change for the somewhat better!" > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Not that it matters much, but I support the counter-proposal based on above. -- 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
This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? You are as such prompted to make a local user account when doing an install from the Live CD. "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 file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command: echo > /etc/securetty Warning A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. " The change will NOT affect: "Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms...The following programs are NOT PREVENTED from accessing the root account: su, sudo, ssh, scp, sftp" On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce wrote: > On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: >> On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: >> > How does someone express strong disagreement to this change ? >> >> Posting here is a good start. You can also add a note in the FESCo ticket >> for approval once one is filed, and if you are incredibly passionate you can >> come to the FESCo meeting (although I'm hoping we can make those meetings >> more efficient, so that's not a good place for back and forth -- if possible >> we should work out the issues before the meeting). > > Ticket number ? > >> > This change makes it very hard to do necessary maintenance. I can >> > understand blocking SSH login as root with password by default, but I do >> > not understand what is the point of blocking console login as root. >> >> I assume that it's for a kiosk or public (or at least managed) lab >> situation. It makes sense for that, but I'm not convinced of a benefit >> otherwise, and I don't think that situation is the default > > I am not even sure it makes sense in a kiosk, unless people want to use > "password" as their root password. But even if it made sense in that > situation it is far from being a useful *default*. This kind of severely > restricting measure is best left to hardening manuals. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > 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
[CHANGE PROPOSAL] The securetty file is empty by default
[CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bug 799556 Closed but not fixed by the Update
Can someone re-open Bug 799556: https://bugzilla.redhat.com/show_bug.cgi?id=799556 I posted there on June 11th, saying it is not fixed. No one has re-opened the bug. Automatic Bug Reported keeps re-directing me to that bug, and is not filing a new bug, because it is considering that as a dupe. But Fedora Update System closed that bug as Fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
