Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Petr Lautrbach]

Ben Beasley  writes:


>      sestatus

This is based on upstream commit d464187c37529c [1]:

policycoreutils: sestatus belongs to bin not sbin

It is quite useful even to non-privileged users and doesn't require any
privileges to work, except for maybe -v.

Some tools hard code the old path, so a compatibility symlink is also
created.

-   install -m 755 sestatus $(DESTDIR)$(SBINDIR)
+   # Some tools hard code /usr/sbin/sestatus ; add a compatibility symlink
+   # install will overwrite a symlink, so create the symlink before calling
+   # install to allow distributions with BINDIR == SBINDIR
+   ln -sf --relative $(DESTDIR)$(BINDIR)/sestatus $(DESTDIR)$(SBINDIR)
+   install -m 755 sestatus $(DESTDIR)$(BINDIR)

So it's should be ready for BINDIR == SBINDIR from upstream POV.

But it can't be built [2] without %{_sbindir}/sestatus until this change
is implemented:

error: Installed (but unpackaged) file(s) found:
   /usr/sbin/sestatus
Installed (but unpackaged) file(s) found:
   /usr/sbin/sestatus


[1] 
https://github.com/SELinuxProject/selinux/commit/d464187c37529ca75fd417174f39ce0eaf13efb5
[2] https://src.fedoraproject.org/rpms/policycoreutils/pull-request/41

Petr


>
> That should be a reasonably accurate list of the executables that need 
> investigation, and for which the packages that provide them probably 
> need some kind of modification.
>
> On 1/7/24 10:47, Gary Buhrmaster wrote:
>> On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney  wrote:
>>> Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>>>
>> I do not see as part of the plan a process to
>> go through all Fedora packages and identifying
>> binaries in /usr/bin that have the same name
>> as a binary in /usr/sbin (from the same, or
>> different packages) such that the packager
>> (or the multiple packages) will need to
>> coordinate the changes (perhaps by engaging
>> upstream).
>>
>> I agree that there should be few, but
>> identifying impacts in advance provides
>> for a better decision process, and minimizes
>> the last minute work that packagers need
>> to do (they will have a longer warning and
>> preparation time).
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Petr Lautrbach]

Ondrej Pohorelsky  writes:

> I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
> As this was the only disputed change in these PRs so far, I plan on merging
> both of them into rawhide at the end of this week.
> However, if you see any issue with merging this "middle ground" change,
> feel free to discuss.
>

```
- %attr(4755,root,root) %{_bindir}/crontab
+ %attr(600,root,root) %{_bindir}/crontab
```

From
https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/monitoring-and-automation/Automating_System_Tasks/

"""
To create a crontab as a specific user, login as that user and type the
command crontab -e to edit the user’s crontab with the editor specified
in the VISUAL or EDITOR environment variable.
"""

If you want to change this you should push the change via Fedora
Change process so it's clearly announced and documented.





> [0]https://src.fedoraproject.org/rpms/cronie/pull-request/12
>
> On Sun, Dec 10, 2023 at 3:37 PM Chuck Anderson  wrote:
>
>> On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
>> > The main effect of the permissions change on these files is that non-root
>> > users can't see any env variables set against the commands scheduled to
>> run.
>> > The actual command lines are still all visible in the proces listing when
>> > the command runs.
>>
>> I think this part alone is worthwhile in a general distro like Fedora,
>> irrespective of any CIS requirements.  Env vars can contain secret
>> data and they are no longer readble by all users in process lists, so
>> changing permissions on cron files fixes a real potential information
>> leak.
>>
>> Also, it is hard to keep file and directory permissions changed from
>> how they are packaged.  The files will become exposed during package
>> updates until some other script comes by and fixes them again.  So it
>> is worthwhile to fix this in the packaging.
>>
>> I agree that the correct middle ground is to fix the permissions, but
>> leave the other parts about cron.allow/cron.deny alone.
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> -- 
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat 
>
> opoho...@redhat.com
> 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: LibuserDeprecation (System Wide)

[Petr Lautrbach]

Steve Grubb  writes:

> On Monday, June 26, 2023 2:47:01 PM EDT Peter Robinson wrote:
>> On Thu, Jun 22, 2023 at 5:15 PM Aoife Moloney  wrote:
>> >
>> >
>> > https://fedoraproject.org/wiki/Changes/LibuserDeprecation
>> >
>> >
>> >
>> >
>> > This document represents a proposed Change. As part of the Changes
>> > process, proposals are publicly announced in order to receive
>> > community feedback. This proposal will only be implemented if approved
>> > by the Fedora Engineering Steering Committee.
>> >
>> >
>> >
>> >
>> > == Summary ==
>> >
>> >
>> >
>> > Libuser is not actively developed. Most of the depending component
>> > have build-time option to work without libuser.
>> >
>> >
>> >
>> > == Owner ==
>> >
>> >
>> >
>> > * Name: [[User:THalman| Tomas Halman]]
>> >
>> >
>> >
>> > * Email: 
>> >
>> >
>> >
>> >
>> > == Detailed Description ==
>> >
>> >
>> >
>> > The libuser provides library and command line utilities to manipulate
>> > user and group information. The purpose of the library
>> > is/was to hide the differences between users in LDAP and files in etc
>> > (passwd, groups...). The support for LDAP
>> > is not complete and there is no plan to extend the functionality.
>> >
>> >
>> >
>> > The LDAP integration in Fedora is nowadays done by SSSD.
>> >
>> >
>> >
>> > In the past, the libuser was used by more component including Fedora
>> > installer. Currently the list is short
>> >
>> >
>> >
>> > * usermode (Requires development, it is not complicated but the
>> > dependency is unconditional)
>> > * util-linux (compile time option)
>> > * passwd (I suggest to ship passwd utility from shadow-utils instead
>> > of passwd and drop passwd package as well)
>> 
>> 
>> Has the maintainer of the passwd utility been engaged about this
>> suggestion? Is there a difference in functionality between the two
>> variants of passwd?
>
> Yes, there is at least one difference that I know of. The one from passwd is 
> SELinux aware. I think that the threat it is defending against is root being 
> a shared account. You can have web admin, db admin, security officer, and 
> other roles. You do not want someone in one of these roles to be able to 
> change the root password and take over / block other admins.
>
> If you run in the unconfined domain, then you would never know it's there. 
> It's when you actually use roles that you bump into this.


Both passwd [1] and shadow-utils passwd [2] use "passwd"
permission to check whether a root user is allowed to change passwords.

In this part the behavior (but output) should not change when
/usr/bin/passwd is replaced with the version from shadow-utils.

e.g. using passwd.shadow from shadow-utils and for "staff" user assigned to
"staff_u" SELinux user with uid 0 it looks like:

[root@fedora ~]# id
uid=0(root) gid=1003(staff) groups=1003(staff) 
context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
[root@fedora ~]# passwd
passwd: SELinux denying access due to security policy.
[root@fedora ~]# passwd.shadow 
passwd.shadow: root is not authorized by SELinux to change the password of 
root



 [1] https://pagure.io/passwd/blob/master/f/selinux_utils.c#_83
 [2] https://github.com/shadow-maint/shadow/blob/master/src/passwd.c#L979


Petr

>
> -Steve
>
>
>> > == Feedback ==
>> >
>> >
>> >
>> >
>> > == Benefit to Fedora ==
>> >
>> >
>> >
>> > The main benefit is to decrease the maintenance and packaging work on
>> > library that does not bring much value while the functionality is
>> > provided by another components.
>> >
>> >
>> >
>> > == Scope ==
>> > * Proposal owners: Dropping the package, move it to EPEL eventually
>> >
>> >
>> >
>> >
>> > * Other developers:
>> >
>> >
>> >
>> > ** Update usermode code to make libuser dependency configurable.
>> > ** Update usermode packaging to compile it without libuser
>> > ** Change packaging of util-linux to compile without libuser dependency
>> > ** Change packaging of shadow-utils to provide passwd utility
>> >
>> >
>> >
>> >
>> > * Release engineering: [https://pagure.io/releng/issue/11492]
>> >
>> >
>> >
>> > Libuser is part of base image and must be removed. IMO mass rebuild is
>> > not required.
>> >
>> >
>> >
>> >
>> > * Policies and guidelines: Since this is about dropping packages
>> > release notes must be updated.
>> >
>> >
>> >
>> >
>> > * Trademark approval: N/A (not needed for this Change)
>> >
>> >
>> >
>> > * Alignment with Community Initiatives: N/A
>> >
>> >
>> >
>> >
>> > == Upgrade/compatibility impact ==
>> >
>> >
>> >
>> > People who used libuser to manipulate users in LDAP will have to move to
>> > SSSD.
>>
>> >
>> >
>> > == How To Test ==
>> >
>> >
>> >
>> > 0. no special hardware needed
>> > 1. remove libuser, passwd, install new shadow-utils, usermod and
>> > util-linux
>  2. try to change password of some user
>> > 3. try to modify user using usermod
>> > 4. expected results: everything works normally
>> >
>> >
>> >
>> > == User Experience ==
>> > This change should not be visible for users.
>> >

Re: F37 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)

[Petr Lautrbach]

Gary Buhrmaster  writes:

> On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach  wrote:
>>
>> Dan Čermák  writes:
>> >
>> > Just out of curiosity, how large is the speedup typically?
>> >
>
>>
>> It depends on the number of threads your machine has. But you could get some
>> data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0
>> restore` on a running system. The following times are reported on my 
>> workstation:
>>
>
> Has anyone run such a test on a system using
> classic ("spinning rust") HDDs?  It is sometimes
> the case that parallelizing activities that are I/O
> intensive can result in excessive seek activity
> that can result in rather elongated elapsed times
> (much worse than single threaded operation).


We have only one machine with a rotary HDD and 4 threads:

# for T in 1 0 4; do chcon -R -t root_t /etc/bad-label/; sync; for i in $(seq 1 
3); do echo $i > /proc/sys/vm/drop_caches; done; echo -T $T; time fixfiles -F 
-T $T restore; done

-T 1
real3m32,046s
user2m0,068s
sys 0m24,005s

-T 0
real2m32,859s
user2m9,265s
sys 0m26,775s

-T 4
real2m38,355s
user2m9,695s
sys 0m27,042s


Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)

[Petr Lautrbach]

Dan Čermák  writes:

> On July 15, 2022 9:42:35 PM UTC, Ben Cotton  wrote:
>>https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
>>
>>This document represents a proposed Change. As part of the Changes
>>process, proposals are publicly announced in order to receive
>>community feedback. This proposal will only be implemented if approved
>>by the Fedora Engineering Steering Committee.
>>
>>
>>== Summary ==
>>After a system's SELinux mode is switched from disabled to enabled, or
>>after an administrator runs `fixfiles onboot`, SELinux autorelabel
>>will be run in parallel by default.
>>
>>== Owner ==
>>* Name: [[User:plautrba| Petr Lautrbach]]
>>* Email: plaut...@redhat.com
>>
>>
>>== Detailed Description ==
>>SELinux tools `restorecon` and `fixfiles` recently gained the ability
>>to relabel files in parallel using the `-T nthreads` option. This
>>option is currently not used in the automatic relabel after reboot.
>>When users want/need the parallel relabeling they have to specify the
>>option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T
>>0` (0 == use all available CPU cores) will be the default for
>>`fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to
>>force it to use only one thread.
>>
>>The rationale is that when autorelabel runs, there are no other
>>resource-intensive processes running on the system, so it's fine (and
>>actually better) to use all available parallelism to speed up the task
>>and get to a fully booted system faster.
>>
>>
>>== Benefit to Fedora ==
>>Faster reboot after switching back to an SELinux enabled system or
>>when triggering autorelabel explicitly.
>
> Just out of curiosity, how large is the speedup typically?
>
>>


It depends on the number of threads your machine has. But you could get some
data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0
restore` on a running system. The following times are reported on my 
workstation:

[root@P1 ~]# time fixfiles -T 0 restore 
Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run 
/run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug 
/sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var
/ 100.0%
...
real1m8.488s
user9m24.755s
sys 0m25.424s

[root@P1 ~]# time fixfiles -T 1 restore 
Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run 
/run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug 
/sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var
/ 100.0%
...
real4m5.450s
user3m55.017s
sys 0m10.088s


Petr

>>== Scope ==
>>* Proposal owners:
>>** Update `/usr/libexec/selinux/selinux-autorelabel` to use `-T 0` by default.
>>
>>* Other developers:
>>* Release engineering:
>>* Policies and guidelines: N/A (not needed for this Change)
>>* Trademark approval: N/A (not needed for this Change)
>>* Alignment with Objectives:
>>
>>
>>== Upgrade/compatibility impact ==
>>
>>
>>== How To Test ==
>># boot with SELinux disabled - add `selinux=0` to the kernel command line
>># reboot
>># store the time it took
>># run `fixfiles -T 1 onboot`
>># reboot
>># the latter reboot should take longer time
>>
>>
>>== User Experience ==
>>Systems should be up and running faster after SELinux autorelabel.
>>
>>== Dependencies ==
>>
>>
>>== Contingency Plan ==
>>* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
>>System Wide Change)
>>* Contingency deadline: N/A (not a System Wide Change)
>>* Blocks release? N/A (not a System Wide Change), Yes/No
>>
>>== Documentation ==
>>
>>N/A (not a System Wide Change)
>>
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Petr Lautrbach]

Petr Lautrbach  writes:

> Kevin Fenzi  writes:
>
>> Greetings everyone. 
>>
>> We finally have everything in place and hopefully tested to make the
>> switch tomorrow from master to rawhide/main branches for
>> src.fedoraproject.org. 
>>
>> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
>> will be moving all the branches over to rawhide/main. As soon as all
>> packages are done, we will be adjusting pdc/hooks/existing pr's.
>>
>> We will be sending an additional email once changes are complete and
>> hopefully any downtime will be limited. 
>>
>> Once the change is completed you will want to checkout rawhide/main
>> instead of master and update/recreate any existing forks you have.
>>
>> See
>> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>> for more information. 
>>
>
> The page says "This Change will move many repositories (see below) to
> use a "main" branch as default." and "Not every namespace on dist-git
> has a rawhide version. For example: containers do not have/use rawhide.
> And having different default branches on different namespaces is not
> very appealing."
>
> Now we have https://src.fedoraproject.org/tests/selinux/ with default
> branch "rawhide". "rawhide" doesn't make sense in this repo as it
> contains tests used on all Fedora versions and also downstream Red Hat
> Enterprise Linux.
>
> Have I missed something?
>
> Petr

I've tried to change it on my own:

1. create and push new branch "real-main"
2. set "real-main" as default branch
3.
^&^ git push origin :rawhide   
remote: Branch deletion is not allowed
remote: Denied push for ref 'refs/heads/rawhide' for user 'plautrba'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/tests/selinux.git
 ! [remote rejected]   rawhide (pre-receive hook declined)
error: failed to push some refs to 
'ssh://pkgs.fedoraproject.org/tests/selinux.git'

4. remove alias main -> rawhide at
https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab

pagure reports: "Alias deleted"

5. refresh the setting page

6. Alias "main" is still there
https://src.fedoraproject.org/tests/selinux/settings#gitbranch-tab

what now? revert changes back to misleading "rawhide"? use "master" as
it's directly referenced in tests we use in Red Hat and solve strange
default branch name later?


Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Petr Lautrbach]

Kevin Fenzi  writes:

> Greetings everyone. 
>
> We finally have everything in place and hopefully tested to make the
> switch tomorrow from master to rawhide/main branches for
> src.fedoraproject.org. 
>
> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> will be moving all the branches over to rawhide/main. As soon as all
> packages are done, we will be adjusting pdc/hooks/existing pr's.
>
> We will be sending an additional email once changes are complete and
> hopefully any downtime will be limited. 
>
> Once the change is completed you will want to checkout rawhide/main
> instead of master and update/recreate any existing forks you have.
>
> See
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> for more information. 
>

The page says "This Change will move many repositories (see below) to
use a "main" branch as default." and "Not every namespace on dist-git
has a rawhide version. For example: containers do not have/use rawhide.
And having different default branches on different namespaces is not
very appealing."

Now we have https://src.fedoraproject.org/tests/selinux/ with default
branch "rawhide". "rawhide" doesn't make sense in this repo as it
contains tests used on all Fedora versions and also downstream Red Hat
Enterprise Linux.

Have I missed something?

Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADSUP: libsepol and libsemanage soname bump

[Petr Lautrbach]

On Wed, Nov 04, 2020 at 09:47:50AM +0100, Petr Lautrbach wrote:
> Hi,
> 
> in order to prevent backward compatibility libsepol and libsemanage used had 
> few
> symbols defined twice and used symbol versioning for them. But when LTO was
> enabled these symbols were completely dropped during compilation, see
> https://github.com/SELinuxProject/selinux/issues/245
> 
> In order to fix it, it was decided to drop these duplicate symbols and also 
> long
> time deprecated symbols and therefore sonames of libsepol and libsemanage were
> bumped.
> 
> The following SELinux userspace components are built and prepared to be 
> merged in
> "f34-build-side-33413" side tag:
> 
> selinux-policy-3.14.7-7.fc34
> setools-4.4.0-0.1.20201102git05e90ee.fc34
> checkpolicy-3.1-4.fc34
> policycoreutils-3.1-5.fc34
> libsemanage-3.1-4.fc34
> libselinux-3.1-4.fc34
> libsepol-3.1-4.fc34
> 
> There are few other components which needs to be rebuild:
> 
> parted - for some reason it links to libsepol even though I haven't found a 
> code
>   which would use it. I've proposed patch upstream
>   
> https://alioth-lists.debian.net/pipermail/parted-devel/2020-November/005500.html
> 
> shadow-utils - https://src.fedoraproject.org/rpms/shadow-utils/pull-request/6
> sssd - https://src.fedoraproject.org/rpms/sssd/pull-request/7
> 
> As none of packages which require either libsepol or libsemanage use dropped
> symbols and in order not to break build root during soname bumps I've added 
> temporary
> subpackages with original library versions - libsepol-compat with 
> libsepol.so.1
> and libsemanage-compat with libsemanage.so.1. These subpackage will be dropped
> as soon as everything is rebuilt in Rawhide.
> 
> I've sucessfuly built all packages also in my COPR repository
> https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/builds/
> 
> If there's no objection I'd like to merge the side tag to rawhide as soon as 
> possible.
> 

This is merged now 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-44f878be7e


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[ELN] Re: HEADSUP: libsepol and libsemanage soname bump

[Petr Lautrbach]

On Wed, Nov 04, 2020 at 03:48:28PM +0100, Miro Hrončok wrote:
> On 11/4/20 3:41 PM, Gary Buhrmaster wrote:
> > On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach  wrote:
> > 
> > > As none of packages which require either libsepol or libsemanage use 
> > > dropped
> > > symbols and in order not to break build root during soname bumps I've 
> > > added temporary
> > > subpackages with original library versions - libsepol-compat with 
> > > libsepol.so.1
> > > and libsemanage-compat with libsemanage.so.1. These subpackage will be 
> > > dropped
> > > as soon as everything is rebuilt in Rawhide.
> > 
> > For some reason I thought lib-compat package
> > naming was deprecated in favor of lib1 package
> > naming (or lib_1 if the last X was a number)
> > for a .1 soname example.  Although as a temporary
> > bypass that is going away before it is exposed in a
> > release I doubt it really matters, but is my understanding
> > correct about the preferred new naming conventions?
> 
> You are correct, "compat" in package names is no longer the proper way.
> 
> See https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
> 

I stand corrected. Thanks.

As of now sssd and shadow-utils are already built the side-tag so they don't
need it anymore. But it could still cause troubles to ELN so I'll remove -compat
packages as soon as I'm sure that they are after this.

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

HEADSUP: libsepol and libsemanage soname bump

[Petr Lautrbach]

Hi,

in order to prevent backward compatibility libsepol and libsemanage used had few
symbols defined twice and used symbol versioning for them. But when LTO was
enabled these symbols were completely dropped during compilation, see
https://github.com/SELinuxProject/selinux/issues/245

In order to fix it, it was decided to drop these duplicate symbols and also long
time deprecated symbols and therefore sonames of libsepol and libsemanage were
bumped.

The following SELinux userspace components are built and prepared to be merged 
in
"f34-build-side-33413" side tag:

selinux-policy-3.14.7-7.fc34
setools-4.4.0-0.1.20201102git05e90ee.fc34
checkpolicy-3.1-4.fc34
policycoreutils-3.1-5.fc34
libsemanage-3.1-4.fc34
libselinux-3.1-4.fc34
libsepol-3.1-4.fc34

There are few other components which needs to be rebuild:

parted - for some reason it links to libsepol even though I haven't found a code
  which would use it. I've proposed patch upstream
  
https://alioth-lists.debian.net/pipermail/parted-devel/2020-November/005500.html

shadow-utils - https://src.fedoraproject.org/rpms/shadow-utils/pull-request/6
sssd - https://src.fedoraproject.org/rpms/sssd/pull-request/7

As none of packages which require either libsepol or libsemanage use dropped
symbols and in order not to break build root during soname bumps I've added 
temporary
subpackages with original library versions - libsepol-compat with libsepol.so.1
and libsemanage-compat with libsemanage.so.1. These subpackage will be dropped
as soon as everything is rebuilt in Rawhide.

I've sucessfuly built all packages also in my COPR repository
https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/builds/

If there's no objection I'd like to merge the side tag to rawhide as soon as 
possible.

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Wed, Sep 16, 2020 at 04:07:11PM +0200, Ondrej Mosnacek wrote:
> On Thu, Sep 10, 2020 at 6:05 PM Robbie Harwood  wrote:
> >
> > Ondrej Mosnacek  writes:
> >
> > > James Cassell wrote:
> > >> Ben Cotton wrote:
> > >>
> > >>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> > >>>
> > >>> == Summary ==
> > >>> Remove support for SELinux runtime disable so that the LSM hooks can
> > >>> be hardened via read-only-after-initialization protections.
> > >>>
> > >>> Migrate users to using ''selinux=0'' if they want to disable SELinux.
> > >>
> > >> I like the proposal. A few thoughts and questions, though:
> > >>
> > >> 1. I think systems with SELINUX=disabled without selinux=0 should
> > >> hard fail very loudly.
> > >
> > > That's an interesting opinion... It would be easier and more direct to
> > > do it that way, but we are worried that users would complain that
> > > their SELINUX=disabled setup is suddenly broken and they need to mess
> > > with the bootloader to get a working system again. (I don't know that
> > > much about real-time systems, so feel free to correct/enlighten me
> > > here.) That's why we try to make sure that things keep working
> > > more-or-less the same as before.
> >
> > Please correct me if I'm wrong, but *aren't* those systems broken?  That
> > is, if an admin sets selinux=disabled on a system after this change has
> > (hypothetically) gone through, won't they have a system in which selinux
> > isn't disabled?  Or is there going to be migration logic in perpetuity?
> 
> I wouldn't say they are broken. They rely on a feature that has been a
> supported and kind-of standard way to disable SELinux until now. After
> this proposal would be implemented, they would still get a state that
> is very close to SELinux being disabled, so I don't think we need to
> go as far as e.g. refusing to boot with such configuration.

And btw, even current /etc/selinux/config describes the future situation:

# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.

^^ this is exactly what will happen when this change is accepted. SELinux will
be enabled internally in kernel but no policy will be loaded and as it was
already explained, for user this situation should be almost the same as  SELinux
disabled. The difference will be only in kernel internal level.


> Of course, it would be great if we could somehow alert the sysadmin
> that they should change their configuration if they have
> SELINUX=disabled in /etc/selinux/config but no selinux=0 on kernel
> cmdline, but I'm not sure if there is an established way to do that in
> Fedora (other than documenting such things in Release notes). On RHEL,
> this is possible via LEAPP or Red Hat Insights, but  what can you do
> on Fedora? Printing warnings/errors anywhere is not reliable, because
> the system (or even a cluster of systems) may be managed only remotely
> with the admin logging in only when something breaks. Or is there some
> established way of telling the admin: "Hey, your system may not seem
> broken, but there is this configuration issue that needs your
> attention."?
> 

Maybe we could add a oneshot systemd unit which would warn users when
/etc/selinux/config contains SELINUX=disabled but it's not disabled in kernel.


Petr

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Thu, Sep 10, 2020 at 03:46:38PM +0200, Michal Schorm wrote:
> Does this mean, the "setenforce 0" won't work anymore?

No, setenforce will not be affected by this change.

> I use it quite a lot to examine the denials and audit2allow to
> generate updated rules which fixes my issues.
> 
> I would see the inability of such workflow as a major drawback for
> *anyone* who doesn't just consume the default configuration.
> e.g. "My database datadir should reside elsewhere"; "my container
> should access pulseaudio socket"; "I've ran the default configuration
> with my data and it crashed" ...
> 

setenforce works only in SELinux enabled system and `setenforce 0` is to put
SELinux in permissive mode (not to disable SELinux), see "SELinux states and 
modes" at 
https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/

Also it will be possible to switch between enforcing and permissive
using SELINUX=enforcing resp SELINUX=permissive in /etc/selinux/config as it is
now.

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Wed, Sep 09, 2020 at 10:24:00AM +0200, Vít Ondruch wrote:
> Generally, I would appreciate if the proposal was more readable to
> casual Fedora user/developer. I don't think there is clearly described
> the current state and what is going to be changed. Also, there is a lot
> of unclear terminology, e.g. I don't have idea what are "LSM hooks".
> "Migrate users to using ''selinux=0''" probably refers to kernel command
> line, but why it is not mentioned in the summary.
> 

I've updated the page to:

- provide links which should descride LSM hooks and 
read-only-after-initialization protection.
- be more decriptive about the cuurent state and the change


https://fedoraproject.org/w/index.php?title=Changes%2FRemove_Support_For_SELinux_Runtime_Disable=revision=587708=587533

Thanks!

Petr

>
> 
> Dne 08. 09. 20 v 17:28 Ben Cotton napsal(a):
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
> > == Owner ==
> > * Name: [[User:plautrba| Petr Lautrbach]]
> > * Email: plaut...@redhat.com
> > * Name: [[User:omos| Ondrej Mosnacek]]
> > * Email: omosn...@redhat.com
> >
> >
> > == Detailed Description ==
> > Support for SELinux runtime disable via ''/etc/selinux/config'' was
> > originally developed to make it easier for Linux distributions to
> > support architectures where adding parameters to the kernel command
> > line was difficult.
> > Unfortunately, supporting runtime disable meant we had to make some
> > security trade-offs when it comes to the kernel LSM hooks.
> >
> > Marking the kernel LSM hooks as read only provides some very nice
> > security benefits, but it does mean that we can no longer disable
> > SELinux at runtime.
> > Toggling between enforcing and permissive mode while booted will
> > remain unaffected and it will still be possible to disable SELinux by
> > adding ''selinux=0'' to the kernel command line via the boot loader
> > (GRUB).
> >
> > System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> > up with ''/sys/fs/selinuxfs'' unmounted,
> > userspace will detect SELinux as disabled. Internally SELinux will be
> > enabled but not initialized so that there will be no SELinux checks
> > applied.
> >
> > NOTE: Runtime disable is considered deprecated by upstream, and using
> > it will become increasingly painful (e.g. sleeping/blocking) through
> > future kernel releases until eventually it is removed completely.
> > Current kernel reports the following message during runtime disable:
> > ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> > cmdline''
> >
> > Additional info:
> >
> > * https://lwn.net/Articles/666550
> > * 
> > https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> > * 
> > https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
> >
> > == Benefit to Fedora ==
> > Marking the LSM hooks as read-only provides extra security hardening
> > against certain attacks, e.g. in case an attacker gains ability to
> > write to random kernel memory locations, with support for disable
> > SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> > bigger chance to turn off (parts of) SELinux permission checking.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Make sure the kernel is built with
> > ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> > ** Make sure the relevant documentation is updated in a way that
> > ''selinux=0'' on kernel command line is the preferred way to disable
> > SELinux.
> > *** 
> > https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> > *** ''selinux(8)'' man page
> > ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> > uses the kernel command line instead of ''/etc/selinux/config'' to
> > disable SELinux.
> > ** Optional: 
> > [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> > ''selinux'' Ansible module] should warn that SELinux needs to be
> > disabled using ''selinux=0''.
> > ** Optional: [https://github.com/linux-system-roles/selinux
> > linux-system-roles.selinux] should disable SELinux using
> > ''selinux=0''.
> >
> > * Other developers: N/A
> 

Re: Package Review SELinux help

[Petr Lautrbach]

On Fri, Jun 26, 2020 at 08:39:19PM +0200, Robert-André Mauchin wrote:
> Hello,
> 
> 
> I know next to nothing about SELinux so I'd like some help about the Bitcoin 
> Package Review by negativo17: 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1834731
> 
> Notably: are the bitcoin.{te,fc,if} files are sane?
> Are they installed properly in the SPEC? Especially these parts:
> 
> %post server
> %systemd_post %{name}.service
> for selinuxvariant in %{selinux_variants}
> do
> /usr/sbin/semodule -s ${selinuxvariant} -i \
> %{_datadir}/selinux/${selinuxvariant}/%{name}.pp \
> &> /dev/null || :
> done
> # FIXME This is less than ideal, but until dwalsh gives me a better way...
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8332 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8333 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18332 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18333 2> /dev/null
> /sbin/fixfiles -R %{name}-server restore &> /dev/null || :
> /sbin/restorecon -R %{_localstatedir}/lib/%{name} || :
> 
> %postun server
> %systemd_postun_with_restart %{name}.service
> if [ $1 -eq 0 ] ; then
> # FIXME This is less than ideal, but until dwalsh gives me a better way...
> /usr/sbin/semanage port -d -p tcp 8332
> /usr/sbin/semanage port -d -p tcp 8333
> /usr/sbin/semanage port -d -p tcp 18332
> /usr/sbin/semanage port -d -p tcp 18333
> for selinuxvariant in %{selinux_variants}
> do
> /usr/sbin/semodule -s ${selinuxvariant} -r %{name} \
> &> /dev/null || :
> done
> /sbin/fixfiles -R %{name}-server restore &> /dev/null || :
> [ -d %{_localstatedir}/lib/%{name} ] && \
> /sbin/restorecon -R %{_localstatedir}/lib/%{name} \
> &> /dev/null || :
> fi
> 
> Please comment in the RR if you can help.
> 
> I find the documentation at https://fedoraproject.org/wiki/SELinux rather old 
> and not really focused on the packaging side of it. Is there guidelines 
> anywhere else?
>

The following document is focused on packaging custom SELinux policies

https://fedoraproject.org/wiki/SELinux/IndependentPolicy

There's also request to incorporate it into oficial Fedora guidelines but the 
process takes some time.

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: SEL: double restorecon on systemupgrade F31->F32

[Petr Lautrbach]

It's already reported - https://bugzilla.redhat.com/show_bug.cgi?id=1832327

It's `fixfiles` issue related to the following file context change:

+ /s?bin/arping  --  system_u:object_r:netutils_exec_t:s0
- /sbin/arping   --  system_u:object_r:netutils_exec_t:s0

`fixfiles` script tries to detect all changes in file contexts and runs 
`restorecon` only on files with changed context. Unfortunately the logic in 
`fixfiles` interprets '/s?bin/arping' as '/*' and runs `restorecon` on '/*'
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing bugzilla overrides coming to dist-git (stg)

[Petr Lautrbach]

On Tue, Mar 17, 2020 at 11:58:40AM +0100, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> A little while ago[1], we integrated anitya in dist-git itself, allowing to
> stop using fedora-scm-request's[2] git repository to store this information.
> 
> However, this git repository is still being used to store bugzilla overrides
> (i.e.: default assignee on bugzilla ticket when they differ from the point of
> contact (main admin) of the package in dist-git).
> 
> Together with Karsten Hopp we worked on integrating this functionality on
> pagure-dist-git[3], thus allowing to get rid entirely of the git repository at
> fedora-scm-request[2].
> 
> This work has been deployed in staging today. We would very much appreciate if
> you could take a few minute of your time and see if it works to your
> liking: https://src.stg.fedoraproject.org/
> 
> The overrides information from production has been migrated yesterday to the
> staging dist-git, so what you see in the UI reflects the current state of the
> overrides in production as of yesterday.
> 


https://src.fedoraproject.org/rpms/setroubleshoot - main admin - 
plaut...@redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1814223 - Assignee Petr Lautrbach

but

https://src.stg.fedoraproject.org/rpms/setroubleshoot - 

Bugzilla Assignee:
Fedora:
dwalsh 
EPEL:
dwalsh 




signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

orphaned vim-vimoutliner

[Petr Lautrbach]

Hi,

I orphaned vim-vimoutliner.

I switched to emacs and haven't touched it for some time.

Thanks,

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] droping file_contexts.bin from selinux-policy-targeted package

[Petr Lautrbach]

On Wed, Nov 01, 2017 at 09:59:29AM +0100, Igor Gnatenko wrote:
> On Wed, 2017-11-01 at 09:46 +0100, Petr Lautrbach wrote:
> > Hi,
> > 
> > we are going to drop file_contexts.bin from selinux-policy-targeted
> > package.
> > 
> > file_contexts.bin file is regenerated by sefcontext_compile utility
> > every time
> > policy is rebuilt, e.g. during update, after semodule -B, ... and
> > this file
> > contains pre compiled pcre regexes from file_contexts.
> > 
> > We added this file to selinux-policy-targeted in order to prevent
> > problems such
> > were [1] [2] but it causes another problems like [3]
> > 
> > Since systemd should be already fixed, it seems to be safe to drop it
> > again and
> > let it create during post install phase.  So we are going to drop it
> > from
> > Rawhide and I think it could be dropped from Fedora 27 as well.
> Am I right that this file will be created on installation? Then you
> should use %ghost to mark it belonging to some package.

Yes, this is the plan.

https://src.fedoraproject.org/fork/plautrba/rpms/selinux-policy/c/dba350c6e03d8747a5524e59ff80cd6277ffa755

If you want to see the changes see

https://src.fedoraproject.org/rpms/selinux-policy/pull-request/3

Thanks,

Petr

> > 
> > I've prepared COPR selinux-policy build [4] without this file. It
> > would be
> > great if someone could test it in some Live image.
> > 
> > With few simple step you can also test how userspace works without
> > *.bin files
> > on a local system:
> > 
> > 1. remove .bin files from /etc/selinux/targeted/contexts/files/
> > 
> > # rm /etc/selinux/targeted/contexts/files/*bin
> > 
> > 2. add/change /etc/selinux/semanage.conf so it contains:
> > 
> > [sefcontext_compile]
> > path = /bin/true
> > [end]
> > 
> > 3. update selinux-policy{,-targeted} from [4]
> > 
> > 4. test it - reboot, relabel, run a desktop session, ...
> > 
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314372
> > [2] https://github.com/systemd/systemd/pull/2508#issuecomment-1882354
> > 77
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1502009
> > 
> > [4] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-policy/b
> > uild/656330/
> > 
> > Thanks,
> > 
> > Petr
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> -- 
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS-UP] droping file_contexts.bin from selinux-policy-targeted package

[Petr Lautrbach]

Hi,

we are going to drop file_contexts.bin from selinux-policy-targeted package.

file_contexts.bin file is regenerated by sefcontext_compile utility every time
policy is rebuilt, e.g. during update, after semodule -B, ... and this file
contains pre compiled pcre regexes from file_contexts.

We added this file to selinux-policy-targeted in order to prevent problems such
were [1] [2] but it causes another problems like [3]

Since systemd should be already fixed, it seems to be safe to drop it again and
let it create during post install phase.  So we are going to drop it from
Rawhide and I think it could be dropped from Fedora 27 as well.

I've prepared COPR selinux-policy build [4] without this file. It would be
great if someone could test it in some Live image.

With few simple step you can also test how userspace works without *.bin files
on a local system:

1. remove .bin files from /etc/selinux/targeted/contexts/files/

# rm /etc/selinux/targeted/contexts/files/*bin

2. add/change /etc/selinux/semanage.conf so it contains:

[sefcontext_compile]
path = /bin/true
[end]

3. update selinux-policy{,-targeted} from [4]

4. test it - reboot, relabel, run a desktop session, ...


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1314372
[2] https://github.com/systemd/systemd/pull/2508#issuecomment-188235477
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1502009

[4] 
https://copr.fedorainfracloud.org/coprs/plautrba/selinux-policy/build/656330/

Thanks,

Petr

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCL and SELinux: help requested

[Petr Lautrbach]

On Tue, Oct 24, 2017 at 12:25:14PM +0200, Petr Lautrbach wrote:
> On Tue, Oct 24, 2017 at 09:10:32AM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
> > Hello, Lukas.
> > Thanks for this thread.
> > 
> > On Monday, 23 October 2017 at 17:50, Lukas Vrabec wrote:
> > > On 10/21/2017 08:48 PM, Kevin Fenzi wrote:
> > [...]
> > > > Also, perhaps it would make sense to move to a more normal looking
> > > > release flow instead of a massive patch? I think that might make it
> > > > easier to see whats going on and how to contribute.
> > > > 
> > > 
> > > This "massive" patch is here because, we diverted from Upsteam policy.
> > > Because Upstream policy is much more strict, you cannot even boot F26+
> > > just with upstream policy. We confine more services then upstream and
> > > we're more benevolent.
> > 
> > The usual way of doing such things is to create a fork from which
> > patches can be merged to the original tree. Surely merging one massive
> > patch is much more difficult than single commits or even series of
> > commits. I assume you do have a fork of the original SELinux policy
> > source tree somewhere, so why don't you simply ship a tarball of your
> > fork instead of upstream+massive patch?
> 
> From selinux-policy.spec:
> 
>26 # Use the following command to create patch from 
> https://github.com/fedora-selinux/selinux-policy
>27 # git diff eb4512f6eb13792c76ff8d3e6f2df3a7155db577 rawhide > 
> policy-rawhide-base.patch
>28 # Use the following command to create patch from 
> https://github.com/fedora-selinux/selinux-policy-contrib
>29 # git diff 64302b790bf2b39d93610e1452c8361d56966ae0 rawhide > 
> policy-rawhide-contrib.patch
> 
> So the fork is at https://github.com/fedora-selinux/selinux-policy and 
> https://github.com/fedora-selinux/selinux-policy-contrib
> 
> There's a document
> https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute
> which is as recent as it could be but it gives insight how

which is NOT as recent as it could be

> does it work. This document should be probably linked directly in spec
> file.
> 
> 
> 
> 
> 
> > > This should change, and we're trying to focus on technical solution
> > > which should decrease amount of maintenance of selinux-policy. We'll
> > > inform you about this project.
> > 
> > If you shared more details about this effort now, you would be more
> > likely to receive help from the community earlier.
> > 
> > > > > Note: If you are interested in writing custom SELinux policy for your
> > > > > package, you can follow the
> > > > > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation
> > > > > on wiki.
> > > > 
> > > > Perhaps you could submit this to the FPC and get it reviewed and moved
> > > > under the normal packaging space?
> > > > 
> > > 
> > > Will do.
> > 
> > Excellent, thank you!
> > 
> > Regards,
> > Dominik
> > -- 
> > Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
> > There should be a science of discontent. People need hard times and
> > oppression to develop psychic muscles.
> > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCL and SELinux: help requested

[Petr Lautrbach]

On Tue, Oct 24, 2017 at 09:10:32AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Hello, Lukas.
> Thanks for this thread.
> 
> On Monday, 23 October 2017 at 17:50, Lukas Vrabec wrote:
> > On 10/21/2017 08:48 PM, Kevin Fenzi wrote:
> [...]
> > > Also, perhaps it would make sense to move to a more normal looking
> > > release flow instead of a massive patch? I think that might make it
> > > easier to see whats going on and how to contribute.
> > > 
> > 
> > This "massive" patch is here because, we diverted from Upsteam policy.
> > Because Upstream policy is much more strict, you cannot even boot F26+
> > just with upstream policy. We confine more services then upstream and
> > we're more benevolent.
> 
> The usual way of doing such things is to create a fork from which
> patches can be merged to the original tree. Surely merging one massive
> patch is much more difficult than single commits or even series of
> commits. I assume you do have a fork of the original SELinux policy
> source tree somewhere, so why don't you simply ship a tarball of your
> fork instead of upstream+massive patch?

From selinux-policy.spec:

   26 # Use the following command to create patch from 
https://github.com/fedora-selinux/selinux-policy
   27 # git diff eb4512f6eb13792c76ff8d3e6f2df3a7155db577 rawhide > 
policy-rawhide-base.patch
   28 # Use the following command to create patch from 
https://github.com/fedora-selinux/selinux-policy-contrib
   29 # git diff 64302b790bf2b39d93610e1452c8361d56966ae0 rawhide > 
policy-rawhide-contrib.patch

So the fork is at https://github.com/fedora-selinux/selinux-policy and 
https://github.com/fedora-selinux/selinux-policy-contrib

There's a document
https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute
which is as recent as it could be but it gives insight how
does it work. This document should be probably linked directly in spec
file.





> > This should change, and we're trying to focus on technical solution
> > which should decrease amount of maintenance of selinux-policy. We'll
> > inform you about this project.
> 
> If you shared more details about this effort now, you would be more
> likely to receive help from the community earlier.
> 
> > > > Note: If you are interested in writing custom SELinux policy for your
> > > > package, you can follow the
> > > > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation
> > > > on wiki.
> > > 
> > > Perhaps you could submit this to the FPC and get it reviewed and moved
> > > under the normal packaging space?
> > > 
> > 
> > Will do.
> 
> Excellent, thank you!
> 
> Regards,
> Dominik
> -- 
> Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] libselinux golang bindings will be dropped from Rawhide

[Petr Lautrbach]

On Tue, Oct 10, 2017 at 05:06:02PM +0200, Zygmunt Krynicki wrote:
> 
> As it's too early to tell which way we'll go with SELinux and golang I
> think it's okay to drop this. Once we start to make some progress into
> making any policy work in snapd we'll either revive this or use a
> maintained package.
> 


According to selinux.go [1] the initial motivation for this
implementation was to add selinux support to docker but this is
maintained by opencontainers now.

Because there are python and ruby bindings in libselinux already, it
would make sense to have also golang bindings if there's any demand.
However, the current implementation needs to be updated and reviewed
before it can be proposed upstream. But I'm not familiar with GO.

So for now, I moved golang bindings to golang-bindings branch [2]
and I will drop it from master branch. It will not be part of the next
libselinux-devel build in Rawhide.


[1] 
https://github.com/fedora-selinux/selinux/blob/golang-bindings/libselinux/golang/selinux.go
[2] https://github.com/fedora-selinux/selinux/tree/golang-bindings

Petr

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] libselinux golang bindings will be dropped from Rawhide

[Petr Lautrbach]

Hi,

libselinux golang bindings [1] haven't been touched since 2014, have
never been upstreamed, nothing requires/uses them in Fedora and since
there's another SELinux golang bindings maintained by opencontainers [2]
I'm going to drop them from Fedora Rawhide.


[1] https://github.com/fedora-selinux/selinux/tree/master/libselinux/golang
[2] https://github.com/opencontainers/selinux

Thanks,

Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Petr Lautrbach]

On 02/23/2017 12:27 AM, Adam Williamson wrote:
> On Thu, 2017-02-23 at 00:22 +0100, Petr Lautrbach wrote:
>>
>> I have a fix for it in setools-4.1.0-1.fc26.6 -
>> https://copr.fedorainfracloud.org/coprs/build/516358/
>>
>>
>> python3-networkx is only required by setools-gui (/usr/bin/apol) and
>> setools-console-analyses (/usr/bin/sedta and /usr/bin/seinfoflow) now.
>>
>> Basic sanity tests provided by policycoreutils and setools passed.
> 
> So long as policycoreutils-python-utils does not require setools-gui
> that sounds like it should fix the problem indeed. Thanks.
> 

It's pushed and built in Rawhide now.

$ rpm -qp --requires policycoreutils-python3-2.6-2.fc26.x86_64.rpm
/usr/libexec/system-python
audit-libs-python3 >= 2.1.3-4
checkpolicy
libcgroup
libselinux-python3
libsemanage-python3 >= 2.6-0
policycoreutils = 2.6-2.fc26
python(abi) = 3.6
python-IPy-python3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
setools-python3

$ rpm -qp --requires setools python3-4.1.0-2.fc26.x86_64.rpm

libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.8)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpython3.6m.so.1.0()(64bit)
python(abi) = 3.6
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

Please let me know if there are any another issues with these builds.

Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Petr Lautrbach]

On 02/22/2017 07:14 PM, Petr Lautrbach wrote:
> On Wed, Feb 22, 2017 at 09:05:14AM -0800, Adam Williamson wrote:
>> On Wed, 2017-02-22 at 17:30 +0100, Petr Lautrbach wrote:
>>>
>>>> Rawhide has been broken since the 15th, First due to nss, then rdma-
>>>> core, followed by policycoreutils and setools breakages. 
>>>
>>> Could you please share more information about policycoreutils and
>>> setools breakages? I haven't noticed any problem or report and I think
>>> we've tested it. I'd like to prevent these problems in future.
>>
>> 'Breakage' is putting it slightly strongly: it's basically a dependency
>> issue. With the new version of setools, setools-python3 replaces
>> setools-libs , and grows a new dependency on python3-networkx .
>> python3-networkx hauls in a whole bunch of other stuff, including
>> python2, perl, texlive and ghostscript stuff.
>>
>> This is problematic because it affects the installer environment. We
>> have this dep chain:
>>
>> docker-anaconda-addon -> docker -> container-selinux ->
>> policycoreutils-python-utils -> policycoreutils-python3
>>
>> pulling policycoreutils-python3 into the installer environment, which
>> means that now, python3-networkx and all its deps get pulled into the
>> installer environment too.
>>
...
>> So we either:
>>
>> 1. Leave the newly-bloated deps in the install root and stop stripping
>> libtiff and avahi-libs
>>
>> 2. Leave the problematic dependency chain in place but try to clean
>> around it in runtime-cleanup somehow
>>
>> 3. Break the problematic dependency chain somewhere
>>
>> For now, releng untagged the new setools and policycoreutils from
>> Rawhide, so composes are running with the old versions (and thus
>> without the problematic dependency chain).
>>
>> I thought someone from releng was going to file a bug on this, but
>> AFAICT they have not, so if they don't soon, I will.
> 
> Thanks for the explanation. I missed this fact, sorry.
> 
> I think it's feasible to break the problematic dependency to other
> subpackages. I'll try to it and push it asap.
> 

I have a fix for it in setools-4.1.0-1.fc26.6 -
https://copr.fedorainfracloud.org/coprs/build/516358/


python3-networkx is only required by setools-gui (/usr/bin/apol) and
setools-console-analyses (/usr/bin/sedta and /usr/bin/seinfoflow) now.

Basic sanity tests provided by policycoreutils and setools passed.

Petr
-- 
Petr Lautrbach



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Petr Lautrbach]

On Wed, Feb 22, 2017 at 09:05:14AM -0800, Adam Williamson wrote:
> On Wed, 2017-02-22 at 17:30 +0100, Petr Lautrbach wrote:
> > 
> > > Rawhide has been broken since the 15th, First due to nss, then rdma-
> > > core, followed by policycoreutils and setools breakages. 
> > 
> > Could you please share more information about policycoreutils and
> > setools breakages? I haven't noticed any problem or report and I think
> > we've tested it. I'd like to prevent these problems in future.
> 
> 'Breakage' is putting it slightly strongly: it's basically a dependency
> issue. With the new version of setools, setools-python3 replaces
> setools-libs , and grows a new dependency on python3-networkx .
> python3-networkx hauls in a whole bunch of other stuff, including
> python2, perl, texlive and ghostscript stuff.
> 
> This is problematic because it affects the installer environment. We
> have this dep chain:
> 
> docker-anaconda-addon -> docker -> container-selinux ->
> policycoreutils-python-utils -> policycoreutils-python3
> 
> pulling policycoreutils-python3 into the installer environment, which
> means that now, python3-networkx and all its deps get pulled into the
> installer environment too.
> 
> Because the entire installer environment is loaded into RAM during
> install, we try quite hard to keep the installer environment *small*.
> Obviously adding 100+ packages of perl/python2/tex cruft to this is a
> problem in itself, but there's a further problem. lorax removes various
>  packages and even individual files from the install root after
> creating it:
> 
> https://github.com/rhinstaller/lorax/blob/master/share/templates.d/99-generic/runtime-cleanup.tmpl
> 
> but it then runs a few checks on the install root that was ultimately
> produced after all the package installation and removal:
> 
> https://github.com/rhinstaller/lorax/blob/master/src/pylorax/treebuilder.py#L151
> 
> including a check that all the libraries that any still-installed
> binary links against are still present. This check now fails because
> libtiff and avahi-libs are removed in 'runtime-cleanup', but several
> binaries from the new dependency chain (from ghostscript, texlive and
> libgeotiff , apparently) are linked against those libraries. You can
> see this happening in the 20170220.n.1 compose, which was attempted
> with the new setools:
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20170220.n.1/logs/x86_64/buildinstall-Everything.x86_64.log
> 
> So we either:
> 
> 1. Leave the newly-bloated deps in the install root and stop stripping
> libtiff and avahi-libs
> 
> 2. Leave the problematic dependency chain in place but try to clean
> around it in runtime-cleanup somehow
> 
> 3. Break the problematic dependency chain somewhere
> 
> For now, releng untagged the new setools and policycoreutils from
> Rawhide, so composes are running with the old versions (and thus
> without the problematic dependency chain).
> 
> I thought someone from releng was going to file a bug on this, but
> AFAICT they have not, so if they don't soon, I will.

Thanks for the explanation. I missed this fact, sorry.

I think it's feasible to break the problematic dependency to other
subpackages. I'll try to it and push it asap.

Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: No More Alphas

[Petr Lautrbach]

On 02/21/2017 03:33 AM, Dennis Gilmore wrote:
> El mar, 21-02-2017 a las 01:56 +0100, Ralf Corsepius escribió:
>> On 02/21/2017 01:48 AM, Kevin Fenzi wrote:
>>> On Tue, 21 Feb 2017 00:14:56 +
>>> "M. Edward (Ed) Borasky" <zn...@znmeb.net> wrote:
>>> ...snip...
>>>
>>>>
>>>> Rawhide as it currently exists can't stay solid enough for me
>>>> even
>>>> with just the few pieces I absolutely need. Tumbleweed, for all
>>>> it's
>>>> promise of "latest and greatest", is not supported by enough
>>>> third
>>>> parties to be useful even as just a host. And sid is, well, sid.
>>>
>>> I'm curious what issues you hit with Rawhide? Have any examples?
>>
>> Current rawhide (== Feb 15) does not match with what the builders
>> use. 
>> => It's impossible to locally investigate runtime bugs
>>
>> Real world example:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1425129
>>
> Rawhide has been broken since the 15th, First due to nss, then rdma-
> core, followed by policycoreutils and setools breakages. 

Could you please share more information about policycoreutils and
setools breakages? I haven't noticed any problem or report and I think
we've tested it. I'd like to prevent these problems in future.

Thanks,

Petr

> it has taken a
> bunch of manual work to get it all figured out, cleaned up and composes
> kicked off, its exactly the types of breakages that I am trying to
> avoid by implementing the change. rawhide as it exists today will still
> exist i the buildsystem. Longer term I would like to extend things to
> do things like automatic rebuilds when we detect breakage. I am sure we
> are not going to get this perfect on day 1, but that over time we will
> improve and make it more and more useful. The goal is to make everyone
> life better. 
> 
> I have started looking at ways to make repos available for early
> testing and debugging problems in builds that have just been built for
> stable fedora's as well. We will have a repo of builds that have been
> built but not released. we will also be working to get notifications to
> developers quicker that a change they made, has broken things. Please
> do not assume that the reason why rawhide is currently a little stale
> is due to intentionally not pushing changes or holding anything back
> because it is not. It is entirely a matter of the type of breakage we
> want to avoid going forward,
> 
> Dennis
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 


-- 
Petr Lautrbach



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS-UP] SELinux userspace 2.6 and SETools-4.1.0 update in Rawhide

[Petr Lautrbach]

Hi,

I'll push builds with updated SELinux Userspace and SETools in to
Rawhide soon.

In the mean time, you can test it from my COPR plautrba/selinux-2.6
repository [1].


SELinux userspace Release 2016-10-14 - 2.6

- sepolicy was converted to SETools 4
- lot of genhomedircon enhancements

For more information about this release see [2]


SETools 4.0.0 and 4.1.0

- this update is needed for policycoreutils-2.6
- tools were reimplemented in Python
- added new tools sedta and seinfoflow
- implemented v30 policy support
- apol - PyQt5 was chosen for the GUI library for SETools

For more information about this releases see [3],[4]



[1] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-2.6/
[2] https://marc.info/?l=selinux=147646050027049=2
[3] https://marc.info/?l=selinux=146237109422331=2
[4] https://marc.info/?l=selinux=148521504308304=2


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fixing /.autorelabel

[Petr Lautrbach]

On 06/30/2016 09:52 PM, Richard W.M. Jones wrote:
> On Thu, Jun 30, 2016 at 09:23:45PM +0200, Petr Lautrbach wrote:
>> On 06/30/2016 06:13 PM, Lennart Poettering wrote:
>>> On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:
>>>
>>>>>> Insert your idea here …
>>>>>
>>>>> Do it the same way `dnf system-upgrade` works. The requirements (having 
>>>>> local filesystem read- and writable) are quite similar. Or the way 
>>>>> PackageKit's system upgrade works…
>>>>> probably the same as (b) though…
>>>>
>>>> This s something I agree with, the system should have an autorelabel
>>>> target that is one-shot just like the system upgrades, and it should
>>>> bring up really the minimal system required to boot and mount the
>>>> filesystem to be relabeled and nothing else, it should work in
>>>> permissive mode and possibly with auditing enabled.
>>>
>>> Yeah, I agree. My suggestion would be for SELinux to provide a systemd
>>> "Generator" tool (see systemd.generator(7) for details) that checks
>>> for the auorelabel flag file or kernel comand line option and then
>>> diverts the boot into a special relabel target that pulls in
>>> local-fs.target and very little else, then does its relabelling and
>>> reboots again. During all of this selinux should be in permissive
>>> mode, after all the labels are generally borked if you boot into this
>>> mode, and hence not suitable for making security decisions.
>>>
>>> Pretty much all of that should live in some selinux package I figure.
>>>
>>
>> I like the idea that the relabeling will be isolated in a special
>> target. And we've recently moved fedora-selinux.service to
>> policycoreutils so it could live there.
>>
>> However, it won't probably fix the following problems:
>>
>> (2) when a generator file was mislabeled it could not be run by systemd
>> as systemd can't read fedora-relabel unit file now
>>
>> Unless we want to loosen the policy to allow systemd read file with any
>> file context, it will be up to a administrator to set a permissive mode
>> via the kernel command line
> 
> I think Lennart's idea still works because he is suggesting that
> SELinux is in Permissive mode during this time.

SELinux policy is loaded in systemd on very beginning so unless it's set
to be permissive in the config file or on the kernel command line, a
system is in enforcing mode until something - in this case a generator
or an service generated by the generator - changes the mode.


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

[Petr Lautrbach]

On 06/30/2016 06:13 PM, Lennart Poettering wrote:
> On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:
> 
>>>> Insert your idea here …
>>>
>>> Do it the same way `dnf system-upgrade` works. The requirements (having 
>>> local filesystem read- and writable) are quite similar. Or the way 
>>> PackageKit's system upgrade works…
>>> probably the same as (b) though…
>>
>> This s something I agree with, the system should have an autorelabel
>> target that is one-shot just like the system upgrades, and it should
>> bring up really the minimal system required to boot and mount the
>> filesystem to be relabeled and nothing else, it should work in
>> permissive mode and possibly with auditing enabled.
> 
> Yeah, I agree. My suggestion would be for SELinux to provide a systemd
> "Generator" tool (see systemd.generator(7) for details) that checks
> for the auorelabel flag file or kernel comand line option and then
> diverts the boot into a special relabel target that pulls in
> local-fs.target and very little else, then does its relabelling and
> reboots again. During all of this selinux should be in permissive
> mode, after all the labels are generally borked if you boot into this
> mode, and hence not suitable for making security decisions.
> 
> Pretty much all of that should live in some selinux package I figure.
> 

I like the idea that the relabeling will be isolated in a special
target. And we've recently moved fedora-selinux.service to
policycoreutils so it could live there.

However, it won't probably fix the following problems:

(2) when a generator file was mislabeled it could not be run by systemd
as systemd can't read fedora-relabel unit file now

Unless we want to loosen the policy to allow systemd read file with any
file context, it will be up to a administrator to set a permissive mode
via the kernel command line


(5) the relabeling service will still need to have StandardInput=tty to
provide a possibility to relabel a system manually


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Rawhide warning: maybe avoid libselinux-2.5-8.fc25

[Petr Lautrbach]

On 06/24/2016 06:04 PM, Adam Williamson wrote:
> Today's Rawhide compose contained no images at all (which is why there
> are no openQA tests for it, in case you wondered). At least some of the
> compose fails (I haven't checked them all) seem to be caused by a
> libselinux bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1349954
> 
> I suspect that complete borkage in libselinux-python may affect quite a
> lot of stuff, though I don't know specifics ATM, so I'd probably
> suggest avoiding updating libselinux for now.
> 

Actually libselinux-2.5-8.fc25 fixes the described problem.

It's related to change in new swig-3.10. New selinux.py module create by
the new swig doesn't use imp.find_module('_selinux',
[dirname(__file__)]) but  importlib.import_module('_selinux') and since
libselinux used to drop its _selinux.so to
/usr/lib64/python3.5/site-packages/selinux/, the module wasn't able to
load it.

# rpm -q libselinux
libselinux-2.5-7.fc25.x86_64

# python3 -c 'import selinux'
Traceback (most recent call last):
  File "/usr/lib64/python3.5/site-packages/selinux/__init__.py", line
18, in swig_import_helper
return importlib.import_module(mname)
  File "/usr/lib64/python3.5/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 986, in _gcd_import
  File "", line 969, in _find_and_load
  File "", line 956, in _find_and_load_unlocked
ImportError: No module named '_selinux'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/site-packages/selinux/__init__.py", line
21, in 
_selinux = swig_import_helper()
  File "/usr/lib64/python3.5/site-packages/selinux/__init__.py", line
20, in swig_import_helper
return importlib.import_module('_selinux')
  File "/usr/lib64/python3.5/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: No module named '_selinux'

# dnf update
...

# rpm -q libselinux
libselinux-2.5-8.fc25.x86_64

# python3 -c 'import selinux'

#


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

HEADS-UP: libselinux will disallow getpidcon() with pid == 0

[Petr Lautrbach]

Hi,

libselinux upstream plans to disallow to use getpidcon(0, ) in sense of
getpidcon(getpid(), )

This behavior has never been documented and it's implementation is
considered error prone.

There seems to be no such case in Fedora but if your project uses
getpidcon() with pid == 0 to get the context of the current process,
please replace it with getcon().

Thanks,


Petr



 Forwarded Message 
Subject: getpidcon with pid == 0 (Was: Re: [PATCH 2/2] libselinux:
procattr: return einval for <= 0 pid args.)
Date: Wed, 24 Feb 2016 09:49:16 -0500
From: Stephen Smalley 
Organization: National Security Agency
To: Daniel Cashman , seli...@tycho.nsa.gov

On 02/23/2016 03:24 PM, Daniel Cashman wrote:
> From: dcashman 
>
> getpidcon documentation does not specify that a pid of 0 refers to the
> current process, and getcon exists specifically to provide this
> functionality, and getpidcon(getpid()) would provide it as well.
> Disallow pid values <= 0 that may lead to unintended behavior in
> userspace object managers.

I'll try to see if there are any legitimate users of getpidcon with pid
== 0.  If anyone on the list knows of one, please speak up.

>
> Signed-off-by: Daniel Cashman 
> ---
>   libselinux/src/procattr.c | 14 --
>   1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libselinux/src/procattr.c b/libselinux/src/procattr.c
> index c20f003..eee4612 100644
> --- a/libselinux/src/procattr.c
> +++ b/libselinux/src/procattr.c
> @@ -306,11 +306,21 @@ static int setprocattrcon(const char * context,
>   #define getpidattr_def(fn, attr) \
>   int get##fn##_raw(pid_t pid, char **c)  \
>   { \
> - return getprocattrcon_raw(c, pid, #attr); \
> + if (pid <= 0) { \
> + errno = EINVAL; \
> + return -1; \
> + } else { \
> + return getprocattrcon_raw(c, pid, #attr); \
> + } \
>   } \
>   int get##fn(pid_t pid, char **c)\
>   { \
> - return getprocattrcon(c, pid, #attr); \
> + if (pid <= 0) { \
> + errno = EINVAL; \
> + return -1; \
> + } else { \
> + return getprocattrcon(c, pid, #attr); \
> + } \
>   }
>
>   all_selfattr_def(con, current)
>






signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2015-10-07)

[Petr Lautrbach]

On 10/08/2015 07:42 AM, Ralf Corsepius wrote:
> On 10/08/2015 07:11 AM, Tomasz Torcz wrote:
>> On Wed, Oct 07, 2015 at 09:56:53PM +, opensou...@till.name wrote:
>>> Note: If you received this mail directly you (co)maintain one of the
>>> affected
>>> packages or a package that depends on one. Please adopt the affected
>>> package or
>>> retire your depending package to avoid broken dependencies, otherwise
>>> your
>>> package will be retired when the affected package gets retired.
>>
>>>
>>> iipsrv (maintained by: trasher)
>>> iipsrv-1.0.0-4.0.git2431b45.fc23.i686 requires /sbin/restorecon
>>>
>>> ipsilon (maintained by: puiterwijk, simo)
>>> ipsilon-base-1.1.0-1.fc24.noarch requires /usr/sbin/restorecon
>>>
>>> ladvd (maintained by: ixs, ttorcz)
>>> ladvd-selinux-1.1.0-4.fc24.i686 requires /sbin/restorecon,
>>> /usr/sbin/semodule
>>>
>>> ocp (maintained by: cra)
>>> ocp-0.1.22-0.6.20150224gita07bf5d.fc23.i686 requires
>>> /sbin/restorecon
>>>
>>> ocsinventory (maintained by: remi, xavierb)
>>> ocsinventory-reports-2.1.2-6.fc23.noarch requires
>>> /sbin/restorecon
>>> ocsinventory-server-2.1.2-6.fc23.noarch requires
>>> /sbin/restorecon
>>
>>So what is correct requires nowadays? /usr/sbin/restorecon?
>> Something else?
> Both should work.
> 
> /usr/sbin/restorecon is a file-provides of the policycoreutils package
> and
> /sbin/restorecon is an explicit provides of the policycoreutils package
> 
> # rpm -qlp policycoreutils-2.4-13.fc24.x86_64.rpm \
>  | grep sbin/restorecon
> ...
> /usr/sbin/restorecon
> 
> # rpm -q --provides -p policycoreutils-2.4-13.fc24.x86_64.rpm \
>  | grep sbin/restorecon
> ...
> /sbin/restorecon
> 
> => Likely, something is broken with the depchecker used to generated the
> reports above.
> 

policycoreutils depends on lzma which was in the orphaned packages list.
But according to pkgdb it's owned again. I'd consider this as already
fixed and next run of depchecker should confirm it.

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

[HEADS UP] policycoreutils - python3 and utilities moved to policycoreutils-python-utils

[Petr Lautrbach]

Hi,

I've just pushed an update of policycoreutils which defaults to python 3
and with python utilities moved from policycoreutils-python to
policycoreutils-python-utils. Both changes were requested by Python team
as part of their Fedora Change [1].

Since the conversion to python 3 is in its early phase and probably not
complete yet, there might occur problems with update and with the
implementation.

Please test and file bugs which should be set to block the change
tracker bug [2] so the python team can provide fixes and help.

[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1076441

Thanks,

Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[HEADS UP] SELinux policy store migration in Rawhide

[Petr Lautrbach]

Hi everybody,

we will do an update of SELinux userspace tools
to 2015-02-02 release and selinux-policy packages as it was proposed in
SELinux policy store migration Fedora system wide change [1].

What does it mean for you:

1. You use only Fedora default SELinux policy.

You shouldn't notice any change but some performance improvements during
regular policy updates.

2. You have local changes in policy like changed booleans, adjusted SELinux
users, added or changed port or file contexts definitions made via
semanage command.

You shouldn't notice any change. All local modifications should be handled
by migration process during packages update.

You can backup your setting using the command below before the update
will happen.

# semanage export -f semanage.mods

3. You have your local SELinux policy modules

You shouldn't notice any change again. All modules should be migrated
during selinux-policy update.

Some of modules could be incompatible with the new policy so they'll
need to be migrated manually. If they are part of any Fedora package,
we will help with the migration. Just file a bug to a component and
add us do CC field.

We are ready to help with other modules or issues with migration on
seli...@lists.fedoraproject.org mailing list.


[1] https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration

Petr
-- 
Petr Lautrbach
-- 
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: SELinux policy store migration

[Petr Lautrbach]

Dne 13.6.2015 v 19:07 Lennart Poettering napsal(a):
 On Fri, 12.06.15 19:00, Miroslav Grepl (mgr...@redhat.com) wrote:
 
 On 06/12/2015 12:17 PM, Lennart Poettering wrote:
 On Thu, 11.06.15 06:51, Jan Kurik (jku...@redhat.com) wrote:

 = Proposed System Wide Change: SELinux policy store migration =
 https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration

 I cannot make sense of this with my limited selinux knowledge, could
 you please elaborate on this on the changes page for people like me
 who only have a superficial understanding of selinux?

 Yeap, we are working on it.

 Basically the binary policy file
 (/etc/selinux/targeted/policy/policy.29) loaded to kernel is built from
 SELinux policy modules. These modules are currently located in
 /etc/selinux/targeted/modules and we call it as a module store. This
 store is now moved to /var/lib/selinux/targeted/modules. This only
 affects tools like semanage, semodule which are used for a policy
 manipulation. So we are able to boot without /var also from SELinux
 point of view.
 
 Why /var and not /usr?
 
 If these module files are shipped with RPMs as vendor versions they
 belong in /usr, no?
 
 What makes this approproate for moving them to /var?
 

Albeit modules are shipped with RPM, SELinux tools (semanage, semodule)
work on this storage to make intended changes. When you enable or
disable modules, when you install modules, when you do changes in
SELinux users, logins and booleans, it's done in SELinux store.



Petr
-- 
Petr Lautrbach



signature.asc
Description: OpenPGP digital signature
-- 
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: SELinux policy store migration

[Petr Lautrbach]

Dne 15.6.2015 v 12:15 Lennart Poettering napsal(a):
 On Mon, 15.06.15 11:15, Petr Lautrbach (plaut...@redhat.com) wrote:
 
 Dne 13.6.2015 v 19:07 Lennart Poettering napsal(a):
 On Fri, 12.06.15 19:00, Miroslav Grepl (mgr...@redhat.com) wrote:

 On 06/12/2015 12:17 PM, Lennart Poettering wrote:
 On Thu, 11.06.15 06:51, Jan Kurik (jku...@redhat.com) wrote:

 = Proposed System Wide Change: SELinux policy store migration =
 https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration

 I cannot make sense of this with my limited selinux knowledge, could
 you please elaborate on this on the changes page for people like me
 who only have a superficial understanding of selinux?

 Yeap, we are working on it.

 Basically the binary policy file
 (/etc/selinux/targeted/policy/policy.29) loaded to kernel is built from
 SELinux policy modules. These modules are currently located in
 /etc/selinux/targeted/modules and we call it as a module store. This
 store is now moved to /var/lib/selinux/targeted/modules. This only
 affects tools like semanage, semodule which are used for a policy
 manipulation. So we are able to boot without /var also from SELinux
 point of view.

 Why /var and not /usr?

 If these module files are shipped with RPMs as vendor versions they
 belong in /usr, no?

 What makes this approproate for moving them to /var?


 Albeit modules are shipped with RPM, SELinux tools (semanage, semodule)
 work on this storage to make intended changes. When you enable or
 disable modules, when you install modules, when you do changes in
 SELinux users, logins and booleans, it's done in SELinux store.
 
 Hmm, I am really not a fan of packages that ship static vendor payload
 in /var. That sounds really wrong. Can't you make this work so that
 only the admin changes end up in /var, but the static data from the
 vendor stays unmodified in /usr? i.e. so that the selinux tools read
 from both directories, and data from /var when in doubt overrides the
 one from /usr?

Right now, we just adopt the new upstream release which doesn't support
more locations for SELinux store.

 The reason I am asking for this: with the stateless system logic we in
 the systemd project and the Atomic folks work on we kinda want to
 ensure that /var only contains data that can be reconstructed at boot
 if necessary, and is hence unessential. This is useful to implement
 stateless systems and factory reset operations, where /var is empty
 on every boot or /var is simply flushed out at times.
 
 Hence: vendor data that stays static should stay in /usr please, and
 only local changes should end up in /var.

This kind of system setup seems reasonable and we'll try to work on it
for future upstream and Fedora releases.

 
 (Note thought that we never asked Fedora formally to support a scheme
 like this, hence what Atomic and we have in mind there is in no way a
 Fedora goal so far, but it would be nice to support this anyway...)
 

Thanks for your comments,

Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
-- 
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: SELinux policy store migration

[Petr Lautrbach]

Dne 11.6.2015 v 14:42 Colin Walters napsal(a):
 On Thu, Jun 11, 2015, at 06:51 AM, Jan Kurik wrote:
 = Proposed System Wide Change: SELinux policy store migration =
 https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration

 Change owner(s):
 * Petr Lautrbach plautrba at redhat dot com
 * Miroslav Grepl mgrepl at redhat dot com

 The newest SELinux userspace project release 2015-02-02 includes a change of 
 the location of the SELinux policy store, which defaults to 
 /var/lib/selinux/. 
 
 This will need to support having an empty /var on boot in order to be 
 compatible
 with both rpm-ostree and the systemd factory reset work.  For most of user 
 space,
 the simplest implementation of this is to just have a systemd-tmpfiles unit 
 that
 copies data on startup.  But policy is currently loaded very early after 
 switch root.  This
 will require that /var be mounted too.

Actually, the policy will be still loaded from /etc/selinux/. The
migration will affect the policy store which is used for rebuilding
policy from modules and from other local changes. So a system could boot
with empty /var if it's needed.

However, we'll probably need to provide  systemd-tmpfiles units in each
selinux-policy-* subpackage to create necessary directory structure.


 It will also mean rpm-ostree rollbacks by default won't affect the selinux 
 policy, which is
 a major and unfortunate change.
 
 The listed benefit is:
 
  -moving the policy store out of /etc
 user could easily get back Factory setup by removing a directory out of 
 /etc

The sub part is not listed anymore. And it's not even true.

 
 Note that OSTree provides that today - all the /etc defaults are copied into
 /usr/etc, so at any point you can easily reset things.  (This is different 
 from
 the systemd effort for an empty /etc).
 
 It seems far simpler to just keep things in /etc, but teach the tools to read
 /usr.  Then *only if* I create a custom local policy, my changes are tracked
 in /etc, and the local compiled policy file lives there too.
 

Thanks for your comments,

Petr
-- 
Petr Lautrbach



signature.asc
Description: OpenPGP digital signature
-- 
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 tcp_wrappers (missing) support for custom acl scripts, aclexec

[Petr Lautrbach]

On 01/11/2015 09:22 PM, Pasi Kärkkäinen wrote:
 Hello,
 
 People who have their names in the Fedora tcp_wrappers changelog added to CC 
 list..
 
 Any comments about the below? Obviously aclexec feature would be useful for 
 all services using tcpwrappers/libwrap (ftp,telnet,tftp,ident,nfs, and many 
 others),
 and thus very nice to have.
 

Hi

please file a RFE bug on tcp_wrappers. I'll try to use the Debian patch.
I'm going to use the Debian patch adding tcpwrappers support in
openssh-6.7p1 likewise.

Petr


 
 On Sat, Jan 10, 2015 at 12:16:38AM +0200, Pasi Kärkkäinen wrote:
 Hello,

 I recently noticed Debian/Ubuntu has had support for aclexec in 
 tcp_wrappers via a custom patch since 2006,
 so you can do this in /etc/hosts.allow or hosts.deny:

 sshd: ALL: aclexec /usr/local/bin/sshfilter.sh %a

 if sshfilter.sh returns true the access is allowed, if sshfilter.sh returns 
 false the access is denied.
 Very handy for integrating DNS RBLs and other IP databases etc.

 What do people feel about that? I'd like to see support for aclexec included 
 in Fedora's tcp_wrappers package.

 I don't think there has been any upstream releases of tcp_wrappers in the 
 near past,
 so that aclexec feature is not upstream.. but the patch that Debian/Ubuntu 
 are using is available.


 Debian tcp_wrappers changelog:
 http://archive.debian.net/changelogs/pool/main/t/tcp-wrappers/tcp-wrappers_7.6.q-16/changelog

 New patch aclexec: adds the aclexec command and its documentation. was 
 added in 2006.


 Thanks,

 -- Pasi

 


-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
-- 
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: Abotu setting 'PermitRootLogin=no' in sshd_config

[Petr Lautrbach]

On 11/21/2014 08:11 AM, P J P wrote:
 Hello,
 
 Sshd(8) daemon by default allows remote users to login as root.
 
   1. Is that really necessary?

The original bug report [1] was kept opened mainly due to the lack of
adding user functionality in anaconda. This is no more true, anaconda
has ability to add an user although it's not enforced.

[1]  https://bugzilla.redhat.com/show_bug.cgi?id=89216

   2. Lot of users use their systems as root, without even creating a non-root 
 user.
  Such practices need to be discouraged, not allowing remote root login 
 could be
  useful in that.

There are several use cases when local non-root users are not needed at
all as others already pointed out.


The change itself is simple however the problem is more complex overall.
Here are some thoughts I have about the change:

- administrators are alerted when they use weak password for root by
anaconda

- Fedora Workstation and Live installations don't enable sshd.service

- even if the default was 'PermitRootLogin without-password' you would
need to inject an ssh key and when you are able to inject a key, you are
able to change the default configuration

- I personally use several Fedora systems without non-root users in
local network.

- default sudoers uses password of an user for authentication, so even
when I have a non-root user in wheel group, I only need one user's
password to become root

- how much users of these enforced users will be 'user' or 'test'?


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Geo-IP/epel7] initial release

[Petr Lautrbach]

commit 5a1bf04e90ec6ab45e78c9f3c114736c713f26f5
Author: Petr Lautrbach plaut...@redhat.com
Date:   Thu Sep 4 11:48:59 2014 +0200

initial release

 perl-Geo-IP.spec |  128 +
 1 files changed, 3 insertions(+), 125 deletions(-)
---
diff --git a/perl-Geo-IP.spec b/perl-Geo-IP.spec
index 24b68d7..b7710bc 100644
--- a/perl-Geo-IP.spec
+++ b/perl-Geo-IP.spec
@@ -1,7 +1,7 @@
 Name: perl-Geo-IP
 Summary:  Efficient Perl bindings for the GeoIP location database
 Version:  1.43
-Release:  2%{?dist}
+Release:  3%{?dist}
 URL:  http://search.cpan.org/dist/Geo-IP/
 License:  GPL+ or Artistic
 
@@ -60,127 +60,5 @@ make test
 
 
 %changelog
-* Wed Sep 03 2014 Jitka Plesnikova jples...@redhat.com - 1.43-2
-- Perl 5.20 rebuild
-
-* Sun Aug 31 2014 Emmanuel Seyman emman...@seyman.fr - 1.43-1
-- Update to 1.43
-
-* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 1.42-5
-- Perl 5.20 rebuild
-
-* Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.42-4
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
-
-* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.42-3
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
-
-* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.42-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
-
-* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 1.42-1
-- 1.42 bump
-
-* Wed Jul 17 2013 Petr Pisar ppi...@redhat.com - 1.40-3
-- Perl 5.18 rebuild
-
-* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.40-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
-
-* Wed Oct 24 2012 Mathieu Bridon boche...@fedoraproject.org - 1.40-1
-- Update to latest upstream release:
-  http://cpansearch.perl.org/src/BORISZ/Geo-IP-1.40/Changes
-
-* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.38-10
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
-
-* Mon Jun 11 2012 Petr Pisar ppi...@redhat.com - 1.38-9
-- Perl 5.16 rebuild
-
-* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.38-8
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
-
-* Fri Jun 17 2011 Marcela Mašláňová mmasl...@redhat.com - 1.38-7
-- Perl mass rebuild
-
-* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.38-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
-
-* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.38-5
-- 661697 rebuild for fixing problems with vendorach/lib
-
-* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 1.38-4
-- Mass rebuild with perl-5.12.0
-
-* Fri Dec  4 2009 Stepan Kasal ska...@redhat.com - 1.38-3
-- rebuild against perl 5.10.1
-
-* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.38-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Mon Jun 15 2009 Michael Fleming mfleming+...@thatfleminggent.com 1.38-1
-- New upstream update (fixes some segfaults and .au timezone breakage)
-
-* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.36-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Thu Aug 28 2008 Michael Fleming mfleming+...@enlartenment.com 1.36-1
-- New upstream update
-
-* Thu Aug 28 2008 Michael Fleming mfleming+...@enlartenment.com 1.34-1
-- New upstream update
-- Source0 updated (new upstream maintainer)
-
-* Sun Apr 13 2008 Michael Fleming mfleming+...@enlartenment.com 1.31-1
-- New upstream update
-
-* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 1.30-3
-- Rebuild for new perl
-
-* Tue Feb 19 2008 Fedora Release Engineering rel-...@fedoraproject.org - 
1.30-2
-- Autorebuild for GCC 4.3
-
-* Mon Jan 28 2008 Michael Fleming mfleming+...@enlartenment.com 1.30-1
-- Update to 1.30. This pulls in much of the PurePerl module for those
-  using it (via third party repositories)
-
-* Mon Sep 3 2007 Michael Fleming mfleming+...@enlartenment.com 1.28-4
-- Fix %%patch invocation to help avoid a bogus interpreter issue
-- First build for Extras
-
-* Sun Aug 26 2007 Michael Fleming mfleming+...@enlartenment.com 1.28-3
-- Actually apply the patch :-)
-- Apply consistency in macro usage
-- Remove explicit GeoIP dependency as it should be pulled in automagically
-- Patch to example/netspeed to avoid bogus interpreter
-- Update License to match current Fedora guidelines.
-
-* Fri Jul 20 2007 Michael Fleming mfleming+...@enlartenment.com 1.28-2
-- Patch out mysterious and ephemeral test failure
-
-* Sun Jul 8 2007 Michael Fleming mfleming+...@enlartenment.com 1.28-1
-- Update to 1.28
-
-* Sun Jun 17 2007 Michael Fleming mfleming+...@enlartenment.com 1.27-4.mf
-- New URLs
-- Fix MakeMaker build requirement
-- Include test suite check

awstats license change

[Petr Lautrbach]

Hello all,

awstats-7.2 upgraded license to GPLv3+.

awstats-7.2-1.fc21 is being built for Rawhide right now.

Regards,

Petr
-- 
Petr Lautrbach



signature.asc
Description: OpenPGP digital signature
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Petr Lautrbach]

On 03/20/2014 08:05 PM, Lennart Poettering wrote:
 On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote:
 
 I doubt there are many people even using them anymore, firewalls are
 more comprehensive and a lot more powerful, and while every admin knows
 firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
 actively make use of them...


 Actually they are used quite a bit in various service worlds. Mainly for
 ssh and email for dealing with scanners. [DenyHosts is a boon in this
 area.] The reason for using a secondary tool is that depth of
 security.
 
 Well, all mails servers as well as sshd have much better ways to do
 such filtering. sshd has Match,  Postfix for example has
 smtpd_client_restrictions=, and so on.

I'd like to note that you can't just replace deny.hosts using Match block in 
sshd_config.

- using libwrap, a connection is dropped before the protocol version exchange 
so a client can't even check the server's
identification string. While using Match block, a client and a server exchange 
id strings, negotiate the transport layer
parameters, exchange keys and establish encrypted connection.

- in Match block, you can only change keywords related to authentication or ssh 
sessions

- every change in sshd_config has to be confirmed by sshd restart, while 
changing hosts.deny doesn't need
any other action

Petr

 Again, I have no doubt that some people still use tcpwrappers. But I'd
 argue that is clearly the excpetion, not the rule, and they'd better use
 something different, and that we should be creating an excellent distro,
 instead of a one that features horrible software...
 
 Over the years I have found that there are multiple of attacks which will
 nullify one layer of protection at one point or another. Having a second
 level or third level of protection is a boon when this happens.
 
 Well, it certainly makes sense to combine a firewall with let's say
 selinux with maybe postfix/ssh acls. Then you already have three layers
 of protection, of very good protection. But of all possible options
 tcpwrap is the absolute worst choice. And we should be able to deprecate
 and remove stuff from our core OS if we think it is crap.
 
 I mean, there are two sides of the medal: sure multiple layers of
 protection might be a good thing, but you also make things a lot more
 complex with each one, and you involve more possibly exploitable code --
 and tcpwrap is simply bad code, that's a fact. So you have to balance
 things out: is something a layer that is worth the trouble? Or does
 having it around make things worse? I am of the opinion that tcpwrap
 indeed does make things worse.
 
 Sure, three layers of condoms probably make sex safer, but then again,
 if one of them is made of 10 year old half-decomposed goat intestines,
 then maybe the sex is a lot less fun, too...
 
 At the enterprise level firewalls can come under a different set of change
 control rules than something like tcpwrappers which is considered
 application level. While I would like to be able to make a simple change in
 a firewall, I can end up spending a month until I can. Application controls
 are usually an hour or so signoff. This means that if tcp-wrappers is going
 then something will need to be able to replace it to meet that large scale
 concern. [Automatic firewall controls like firewalld have to be disabled or
 put into a manual changes only mode in these areas for change control
 purposes. ]
 
 Well, that really sounds like a specific issue of your
 company... Really, I don't think the question whether the bureaucracy of
 some hypothetical company makes a distinction between tcwrap and
 firewalls has no place in the discussion whether we should support
 tcpwrap in our distro or not.
 
 I can't argue on the code maintainability or layout. Not my area of
 expertise. I can say that if tcpd/libtcpwrappers were to go away that
 something equivalent would need to be built to replace it for the ability
 to fine tune at a layer below the firewall.
 
 Why? Other than your hypothetical bureaucracy, is there anything that
 tcpwrap can do that firewalls can't do, that really deserves to be
 supported? I really can't see anything... [1]
 
 tcpd comes from a time when there weren't local firewalls available in
 all Unix systems, so they built something like them in userspace. But
 that time is long long gone, and pretty much any Linux installation I
 know nowadays has a firewall compiled into the kernel...
 
 Lennart
 
 
 
 [1] well, sure tcpwrap resolves DNS dynamically and can use that for
 access control, but people who bind access control to DNS really should
 find a different job than administrator...
 

-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Petr Lautrbach]

On 03/28/2014 02:44 PM, Reindl Harald wrote:
 - every change in sshd_config has to be confirmed by sshd restart, while 
 changing hosts.deny doesn't need
 any other action
 
 no - try it out!
 
 make a fatal syntax error in sshd_config and in case of a
 remote machine make sure you don't close the last connection
 because you will not reach the machine again otherwise
 
 

[14:46:53 root@malas ~ ]# /usr/sbin/sshd -T
/etc/ssh/sshd_config: line 157: Bad configuration option: blbla
/etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a Match 
block
[14:46:55 root@malas ~ ]# ssh localhost
Fedora release 21 (Rawhide)
root@localhost's password:


Petr
-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.



signature.asc
Description: OpenPGP digital signature
-- 
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: rawhide report: 20130307 changes

[Petr Lautrbach]

On 7.3.2013 16:00, Richard W.M. Jones wrote:

On Thu, Mar 07, 2013 at 02:10:08PM +, Fedora Rawhide Report wrote:

[kdebase3]
kdebase3-pim-ioslaves-3.5.10-21.fc18.x86_64 requires 
libsasl2.so.2()(64bit)
[kdevelop-python]
kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0
kdevelop-python-1.4.1-2.fc19.x86_64 requires 
libpython2.7-kdevelop.so.1.0()(64bit)
[libgda]
1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit)
[libguestfs]
1:libguestfs-1.21.17-1.fc19.i686 requires libsasl2.so.2
1:libguestfs-1.21.17-1.fc19.i686 requires /usr/lib/sasl2/libsasldb.so.2
1:libguestfs-1.21.17-1.fc19.i686 requires 
/usr/lib/sasl2/libanonymous.so.2
1:libguestfs-1.21.17-1.fc19.x86_64 requires libsasl2.so.2()(64bit)
1:libguestfs-1.21.17-1.fc19.x86_64 requires 
/usr/lib64/sasl2/libsasldb.so.2
1:libguestfs-1.21.17-1.fc19.x86_64 requires 
/usr/lib64/sasl2/libanonymous.so.2

[and more ...]

Unintentional soname bump in cyrus-sasl-lib?  Looking at the package
it seems that the soname has gone from .2 to .3, even though the
package version did not change significantly (2.1.26-5 - 2.1.26-6).



No, it's intentional, see [1]. There were a transition period when 
cyrus-sasl-lib carried both libsasl2.so.2 and libsasl2.so.3 but some 
packages weren't rebuilt during f19 mass rebuild for some reason so they 
still require libsasl2.so.2.



[1] http://lists.fedoraproject.org/pipermail/devel/2013-January/176599.html

Petr
--
Petr Lautrbach plaut...@redhat.com, Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Petr Lautrbach]

On 01/23/2013 10:53 AM, Petr Pisar wrote:

On 2013-01-22, Petr Lautrbachplaut...@redhat.com  wrote:


I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of
this update is also SONAME bump to libsasl2.so.3.

The main issue with this update is that it would break buildroot since
there is the openldap package requiring libsasl2.so.2 which is part of
buildroot.


Is this the only problem? Or do you expect patching reverse dependencies
is needed?


I don't expect any other problems than reverse dependencies with openldap.

abi-compliance-checker [1] reports only low symbol problems and changed 
constants.
But soname bump is still needed and it's also part of upstream release/



If the only problem is SONAME bump in minimal buildroot, just copy the old
library from system into 2.1.26 at build time. This way you get both
versions available at the same time. Then rebuild reverse dependencies
(in miminimal build root only), and finally rebuild cyrus-sasl to spit
the old library out.


I originally thought about temporary fake provide of libsasl2.so.2, but this 
seems to me
more robust.



If you are not proven packager I can help you with rebuild.



Thanks, I'll let you know.


[1] http://plautrba.fedorapeople.org/cyrus-sasl/compat-report-2.1.23-2.1.26.html


Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Petr Lautrbach]

Hi all,

I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this 
update
is also SONAME bump to libsasl2.so.3.

The main issue with this update is that it would break buildroot since there is 
the openldap
package requiring libsasl2.so.2 which is part of buildroot. So I'll do needed 
steps in co-operation
with Jan Vcelak - the openldap maintainer - in order not to break it.

There are also several other packages dependent on libsasl2.so.2 [1], which 
will need rebuild.
It's my understanding that there will be mass rebuild soon so I wouldn't 
rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?

Thanks,

Petr

[1] # repoquery -s --whatrequires --alldeps 'libsasl2.so*' | uniq
389-admin-1.1.31-1.fc19.1.src.rpm
389-ds-base-1.3.0.2-1.fc19.src.rpm
389-dsgw-1.1.9-3.fc18.src.rpm
argus-3.0.4-3.fc18.src.rpm
autofs-5.0.7-10.fc19.src.rpm
claws-mail-3.9.0-1.fc19.src.rpm
cyrus-imapd-2.4.17-1.fc19.src.rpm
cyrus-sasl-2.1.25-2.fc19.src.rpm
ekiga-4.0.0-2.fc19.src.rpm
evolution-data-server-3.7.4-1.fc19.src.rpm
exim-4.80.1-1.fc19.src.rpm
freeipa-3.1.0-1.fc19.src.rpm
gtk-vnc-0.5.1-5.fc19.src.rpm
kdebase3-3.5.10-21.fc18.src.rpm
kdepim-4.9.97-1.fc19.src.rpm
kdepimlibs-4.9.98-1.fc19.src.rpm
libetpan-1.1-3.fc18.src.rpm
libguestfs-1.21.2-2.fc19.src.rpm
libmemcached-1.0.15-1.fc19.src.rpm
nufw-2.4.3-6.fc18.src.rpm
pidgin-2.10.6-4.fc19.src.rpm
libvirt-1.0.1-4.fc19.src.rpm
mozldap-6.0.5-9.fc18.src.rpm
mutt-1.5.21-16.fc19.src.rpm
myproxy-5.9-2.fc19.src.rpm
nss_ldap-265-10.fc17.src.rpm
nufw-2.4.3-6.fc18.src.rpm
openldap-2.4.33-3.fc19.src.rpm
php-5.4.11-1.fc19.src.rpm
postfix-2.9.5-2.fc19.src.rpm
ptlib-2.10.9-1.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
qca-cyrus-sasl-2.0.0-0.4.beta3.fc18.src.rpm
qemu-1.3.0-3.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
rinputd-1.0.5-1.fc19.src.rpm
ruby-qpid-0.8-7.fc18.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
samba-4.0.1-1.fc19.src.rpm
sendmail-8.14.6-2.fc19.src.rpm
spice-gtk-0.16-1.fc19.src.rpm
spice-0.12.2-2.fc19.src.rpm
squid-3.2.5-1.fc19.src.rpm
subversion-1.7.8-3.fc19.src.rpm
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump

[Petr Lautrbach]

On 01/22/2013 03:53 PM, Bruno Wolff III wrote:

On Tue, Jan 22, 2013 at 15:19:18 +0100,
Petr Lautrbach plaut...@redhat.com wrote:

It's my understanding that there will be mass rebuild soon so I wouldn't 
rebuild all of them manually,
but I would wait for this rebuild.

Comments? Suggestions?


The rebuild will likely be in a side tag and things won't be fixed until the 
rebuild is complete. It may be better to do the manual rebuild for the affected 
packages.


At first I'd planned to do it manually so I requested a tag for these rebuilds 
too [1]. But with oncoming mass rebuild
I'm not really sure if I can manage all rebuilds before main rebuild given that 
I'm not a proven packager.

[1] https://fedorahosted.org/rel-eng/ticket/5451

Petr


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [@core] working definition for the minimal package set

[Petr Lautrbach]

On 11/12/2012 06:10 PM, Seth Vidal wrote:




On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote:


On 11/12/2012 06:03 PM, Seth Vidal wrote:




On Mon, 12 Nov 2012, Tomas Mraz wrote:


On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote:



On Mon, 12 Nov 2012, Matthew Miller wrote:


On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote:

I think ssh has to be in the mix. Of ths systems I use/maintain/etc
very few of them are ones I actually have a reliable console to.
If ssh isn't there, I have to add it just to get the system set up.


Yeah: if we get to the point where every real install has to add the same
subset of packages to core, I don't think we've succeeded in doing
anything
except make more work for the whole world.

A cron daemon and (at least basic) MTA fall in the same area, I think.
But what about ssh-clients?

Is there a reasonable yardstick rule we can make, or is it pragmatically
best to just make per-package decisions?



so - imo

openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/


Perhaps scp could be moved to the base openssh package then.



Sounds reasonable to me.


Not sure that's a good idea. ssh itself is also part of the clients
package and should probably moved as well then. sftp is probably popular
too. I think its better to bite the bullet and just include the clients
package as a whole.



i think you misunderstand.

if I am attempting to connect to a server running sshd:

I can run

ssh servername

and that works

I can run
sftp servername
and THAT works

I cannot run
scp servername

I have to have a local scp client installed on the server for scp to work as a 
service.



scp is a ssh client. It connects to other host using a ssh connection and runs 
'scp -t' or 'scp -f'
commands on the remote side. From my point of view, it's same as any other 
program you can use via
ssh and I believe that openssh-clients is the right place for it.

sftp subsystem is configured by default so you can use it if you need transfer 
files to minimal system.

Petr
--
Petr Lautrbach, Red Hat, Inc.
http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [@core] working definition for the minimal package set

[Petr Lautrbach]

On 11/12/2012 06:44 PM, Seth Vidal wrote:




On Mon, 12 Nov 2012, Petr Lautrbach wrote:


scp is a ssh client. It connects to other host using a ssh connection and runs 
'scp -t' or 'scp -f'
commands on the remote side. From my point of view, it's same as any other 
program you can use via
ssh and I believe that openssh-clients is the right place for it.

sftp subsystem is configured by default so you can use it if you need transfer 
files to minimal system.



which was, in fact, what I said.

scp is something people expect to be able to use on servers to send files over. 
that it is not there makes the server install feel a touch awkward.

that's all.


A thin client would probably not want to install openssh-server.

Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: still UsrMove problems and wrong PATH in openssh

[Petr Lautrbach]

On 10/31/2012 10:47 AM, Reindl Harald wrote:

it is REALLY bad make UsrMove and HRADCODE /bin:/sbin
in PATH of openssh, this results in packages built
with rpmbuild having Requires: /bin/perl as example

in my opinion rpmbuild should know about the change
and fix implicit Requires: /bin and Requires: /sbin


rpmbuild could have tried realpath first:

# rpm -ql perl | grep -E '^/bin/perl'

# realpath /bin/perl
/usr/bin/perl

# rpm -ql perl | grep -E '^/usr/bin/perl'
/usr/bin/perl
/usr/bin/perl5.16.1
/usr/bin/perlbug
/usr/bin/perlthanks




https://bugzilla.redhat.com/show_bug.cgi?id=856590
WHY are F18 packages built for testing if a bugreport
is for F17 - if someone is working hard to get F17
running as F16 before this is not helpful


I usually try to fix bugs in latest versions and then backport fixes back to 
older releases.
In this case, the bug was accidentally closed by F18 update and since it's 
closed it
went out of my sight. Also I missed you comment. I'm sorry. Feel free to reopen
a bug if you think that an issue is not fixed.

Here's an update https://admin.fedoraproject.org/updates/openssh-5.9p1-27.fc17


petr
--
Petr Lautrbach, Red Hat, Inc.
http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: upstart → systemd upgrade path issue

[Petr Lautrbach]

On 05/25/2011 09:33 PM, Rahul Sundaram wrote:
 On 05/25/2011 04:34 PM, Petr Lautrbach wrote:
 upstart-1.2-2 hasn't changed upstart behavior. It fixes upstream bugs and 
 also adds new
 features like new stanzas (manual,debug) and also .override files
 feature adapted from Ubuntu.

 We don't do feature additions like this in a existing release unless
 there is a very good reason to.  There is no reason to since we aren't
 using any of those new features in Fedora anyway.  Why would you ignore
 the update policy in a critical path package?

 http://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages


Ok, I admit that I should have sent announcement to allow wider awareness.

upstart-1.0 branch is in fact minor update of upstart-0.6.5, it was just 
declared stable.

.override files [1] in upstart allows admin to change behaviour of upstart job 
without changing
original file so that change will remain after package update. e.g. if I didn't 
want allow users
to use ctr-alt-del to reboot system, I would create 
/etc/init/control-alt-del.override file with manual
stanza. This sounds for me as very good reason to add this.


[1] http://upstart.at/2011/03/11/override-files-in-ubuntu-natty/

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: upstart → systemd upgrade path issue

[Petr Lautrbach]

On 05/26/2011 12:44 PM, Rahul Sundaram wrote:
 On 05/26/2011 03:45 PM, Petr Lautrbach wrote:
 Ok, I admit that I should have sent announcement to allow wider awareness.

 upstart-1.0 branch is in fact minor update of upstart-0.6.5, it was just 
 declared stable.

 .override files [1] in upstart allows admin to change behaviour of upstart 
 job without changing
 original file so that change will remain after package update. e.g. if I 
 didn't want allow users
 to use ctr-alt-del to reboot system, I would create 
 /etc/init/control-alt-del.override file with manual
 stanza. This sounds for me as very good reason to add this.

 I don't see how.  How are you taking advantage of these new features in
 Fedora 14?

Example I mentioned solves https://bugzilla.redhat.com/show_bug.cgi?id=612175 
also for F14.

There was no way to permanently change or disable upstart job in previous 
release.
Files in /etc/init/ are not mark as %config since they are more initscripts 
than
real configs. So every change would be lost after package update.

I can simply overwrite any part of job using /etc/init/job.override with this 
update
and my changes will survive updates.

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: upstart → systemd upgrade path issue

[Petr Lautrbach]

On Wed, May 25, 2011 at 11:33:50AM +0200, Kevin Kofler wrote:
 Hi,
 
 today this update:
 https://admin.fedoraproject.org/updates/upstart-1.2-2.fc14
 got pushed to F14. (FWIW, I don't see how this is consistent with the update 
 policies, but that's not the matter here.)

Hi,

upstart-1.x branch is considered as stable and it's recommended update, see [1]
 
upstart-1.2-2 hasn't changed upstart behavior. It fixes upstream bugs and also 
adds new
features like new stanzas (manual,debug) and also .override files
feature adapted from Ubuntu.

 The result is that systemd in F15 no longer Obsoletes the upstart in F14:
 https://bugzilla.redhat.com/show_bug.cgi?id=707507
 
 This is going to break upgrades from F14 to F15 for many of our users. :-(
 

Upgrade still installs systemd. systemd provides systemd-sysvinit which is 
required
by initscripts. 

There is only issue is that upstart is not uninstalled and pulls
initscripts-legacy as pointed in [2].

[1] 
http://upstart.at/2011/03/02/upstart-1-0-this-is-a-fertile-land-and-we-will-thrive-released/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=707507#c5


Petr
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning awstats

[Petr Lautrbach]

On Tue, Nov 30, 2010 at 08:21:32AM +0100, Aurelien Bompard wrote:
 Hi all,
 
 I'm orphaning awstats, a web log file analyzer.
 If anyone's interested...
 

I will take it.

Petr
-- 
Petr Lautrbach, Red Hat, Inc. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

upstart and /var/{lock,run} on tmpfs in Rawhide

[Petr Lautrbach]

Hello,

upstart (upstart-0.6.6-3.fc15) now includes tmpfiles job 
(/etc/init/tmpfiles.conf) which looks
for /var/{lock,run}/* directories configured via /etc/tmpfiles.d/* files and 
tries to create them
if they don't exist.

It allows to switch to upstart without tmpfs on /var/{lock,run} even if some 
packages were
already installed on system with systemd/tmpfs feature.

You can also use /var/{lock,run} on tmpfs in similar way as is configured with 
systemd. You will
only need to add following lines to /etc/fstab:
tmpfs  /var/run  tmpfs   rw,noexec,nosuid,nodev,mode=755
   0 0
tmpfs  /var/lock tmpfs   rw,noexec,nosuid,nodev,mode=775,gid=54 
   0 0


Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

[Petr Lautrbach]

On 11/23/2010 09:48 PM, Lennart Poettering wrote:
 Heya!

...
 - Many .spec files currently own subdirs of /var/run. These need to be
updated to %ghost those dirs only, so that the automatic removal of
these files/dirs on boot doesnt cause rpm to complain. The list of packages
which own such files/subdir you find on the aforementioned feature
page. I will mass-file bugs against these packages later tonight,
requesting the %ghosting of these entries. For more information on the
%ghost directive in .spec files see this page:


 http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-FLIST-GHOST-DIRECTIVE

I think this is not needed. Files in /var/lock and /var/run are already cleaned 
by
rc.sysinit during boot process hence they should be already %ghost-ed now.

rpm doesn't complain on re-created directories:

# rpm -qf /var/run/abrt/
abrt-1.1.14-1.fc15.x86_64
# rm -rf /var/run/abrt/
# rpm -qV abrt
missing /var/run/abrt
# mkdir /var/run/abrt/
# rpm -qV abrt
#

So it should be sufficient to include them in /etc/tmpfiles.d/...conf and leave 
them as regular dirs in package.

This would have minimal impact to changes in .spec files (no new scriplets 
needed) and also to configurations
without tmpfs on /var/{run,lock}

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: experimental systemd + initscripts repo

[Petr Lautrbach]

On 10/21/2010 04:43 PM, Bill Nottingham wrote:
 I've set up a repo on r.fp.org:
http://repos.fedorapeople.org/repos/notting/initscripts-systemd/

 This repo includes updated initscripts and associated packages
 that test the conversion of various boot-time actions to systemd
 services. (Essentially, rc.sysinit is dead.) Before putting this
 in rawhide, we want to make sure it's not too horribly broken.

 Feedback welcome in bugzilla (against initscripts) or on the list.
 There may be additional changes pushed to the repo as more things
 are moved to native systemd services.

 Bill

Since initscripts-legacy is complement to initscripts
initscripts-legacy should have
Requires: %{name} = %{version}-%{release}


Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upstart conflicting with systemd in rawhide (BR on /sbin/shutdown)

[Petr Lautrbach]

On 10/15/2010 09:16 AM, Stanislav Ochotnicky wrote:
 Error: upstart-sysvinit conflicts with systemd
 Error: Package: tomcat5-5.5.27-7.4.fc12.noarch (fedora)
 Requires: jaf = 1.0.2
 Available: classpathx-jaf-1.0-15.1.fc12.x86_64 (fedora)
 jaf = 1.0.2
   You could try using --skip-broken to work around the problem
 Error: Package: classpathx-mail-1.1.1-9.1.fc12.x86_64 (fedora)
 Requires: jaf= 1.0
 Available: classpathx-jaf-1.0-15.1.fc12.x86_64 (fedora)
 jaf = 1.0.2
 Error: systemd conflicts with upstart-sysvinit
   You could try running: rpm -Va --nofiles --nodigest


Hi,

this is fixed with upstart-0.6.5-12.fc15 [1] which drops upstart-sysvinit and 
should
hit rawhide soon.

[1] http://lists.fedoraproject.org/pipermail/devel/2010-October/144375.html

Regards,

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: upstart in rawhide

[Petr Lautrbach]

On 10/15/2010 01:13 AM, Kevin Kofler wrote:
 Petr Lautrbach wrote:
 systemd will be default init system in Fedora 15 and scripts
 infrastructure will be adapted to it. There is a plan to leave upstart in
 Fedora as non-official alternative.

 I don't think this is a good idea at all. We want users still on upstart to
 get automatically migrated to systemd, so having systemd obsolete upstart at
 RPM level is the best way to get there. I also don't see what we have to
 gain from having a redundant init system in the distribution.


For now is obsolete mechanisms replaced by dependency upstart on 
sysinit-userspace
which is provided by systemd. So that you will use/boot to systemd after
update to upstart-0.6.5-12.fc15 unless you have 'init=/sbin/upstart'


Regards,

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

upstart in rawhide

[Petr Lautrbach]

Hello,

systemd will be default init system in Fedora 15 and scripts infrastructure 
will be adapted to it.
There is a plan to leave upstart in Fedora as non-official alternative.

For now (since upstart-0.6.5-12.fc15):

- upstart-sysvinit is no longer created

- upstart requires sysvinit-userspace (now provided by systemd) which provides 
upstart compatible
utilities /sbin/halt,poweroff,reboot,shutdown,telinit

- conflicting upstart utilities are located in /lib/upstart

- jobs definitions in /etc/init/ are already packaged in upstart but still taken
from initscripts upstream git

- to use upstart as init you need to pass init=/sbin/upstart to kernel command 
line e.g. via grub.conf


There will be probably more changes like resolving file conflicts on /sbin 
utilities, rc.sysinit,
/etc/init.d/halt and man pages which are currently not shipped.


Any objections and comments are appreciated.

Regards,

Petr
-- 
Petr Lautrbach, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Licensing Guidelines Update - Please Read

[Petr Lautrbach]

On 07/07/2010 10:29 PM, Tom spot Callaway wrote:
 [plautrba] finger: finger-server-0.17-39.fc12.x86_64

Fixed and built for Rawhide.

Petr
-- 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel