Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

On Thu, 29 Mar 2018 21:32:21 -0400, "Theodore Y. Ts'o" said: > Yes, the breakage is my fault; my apologies. The new version of the > patch is already posted in bugzilla (and on linux-ext4). I'll be > pushing out a refreshed ext4.git branch shortly. Confirming that reverting

Re: [PATCH 1/1] libsepol/cil: Improve processing of context rules

In Android we have a problem when .cil files from different partitions with duplicate genfscon statements are built together. I've checked that this commit fixes the problem. Thank you! On Thu, Mar 29, 2018 at 1:14 PM, jwcart2 wrote: > Pierre-Hugues Husson, I've tested

[PATCH v3 0/2] restorecon context validation improvement

In permissive, if a bad label is written to a file_context file, restorecon will not verify the label before succesfully applying the context. These patches fix validation of labels during restorecon while not breaking current behavior of lazy validation. Changes since V1: - Continue using lazy

[PATCH v3 1/2] libselinux: verify file_contexts when using restorecon

In permissive mode, calling restorecon with a bad label in file_contexts does not verify the label's existence in the loaded policy. This results in any label successfully applying to a file, as long as the file exists. This issue has two assumptions: 1) file_contexts must be manually updated

[PATCH v3 2/2] libselinux: echo line number of bad label in selabel_fini()

Keep track of line numbers for each file context in selabel_handle. If an error occurs in selabel_fini(), the line number of an invalid file context is echoed to the user. Signed-off-by: Yuli Khodorkovskiy --- libselinux/src/label.c | 2 +- libselinux/src/label_file.h

Re: [PATCH 1/1] libsepol/cil: Improve processing of context rules

The commit message and the code match my needs, and the few tests (not unit tests at all though) I have are passing. I'll test it on real devices, and I'll report back if anything seem wrong. Just as a reminder, the only problems I hit for the moment are on genfscon, so that's the only thing I've

Re: [PATCH 1/1] libsepol/cil: Improve processing of context rules

Pierre-Hugues Husson, I've tested and everything seems to work as I expect it, but does this meet your needs? Jim On 03/29/2018 04:06 PM, James Carter wrote: Improve the processing of netifcon, genfscon, ibpkeycon, ibendportcon, portcon, nodecon, fsuse, filecon, iomemcon, ioportcon,

[PATCH 1/1] libsepol/cil: Improve processing of context rules

Improve the processing of netifcon, genfscon, ibpkeycon, ibendportcon, portcon, nodecon, fsuse, filecon, iomemcon, ioportcon, pcidevicecon, and devicetreecon rules. If the multiple-decls option is not used then report errors if duplicate context rules are found. If it is used then remove

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

On 03/29/2018 02:29 PM, Stephen Smalley wrote: > On 03/29/2018 01:57 PM, valdis.kletni...@vt.edu wrote: >> Seeing this error trying to mount ext4 disks. next-20180320 was OK. >> >> SELinux: (dev dm-3, type ext4) getxattr errno 34 >> >> and for /var, it refused to mount entirely (which brought the

Re: linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

On 03/29/2018 01:57 PM, valdis.kletni...@vt.edu wrote: > Seeing this error trying to mount ext4 disks. next-20180320 was OK. > > SELinux: (dev dm-3, type ext4) getxattr errno 34 > > and for /var, it refused to mount entirely (which brought the boot > process to a screeching halt). > > git log

Re: [PATCH v2 1/1] Detect identical genfscon

2018-03-23 0:04 GMT+01:00 Pierre-Hugues Husson : > From: Pierre-Hugues Husson > > Currently secilc doesn't deal with duplicate genfscon rules > > This commit fixes this, and implements multiple_decls behaviour. > > To reduce the code changes, the compare function

linux-next 20180327 - "SELinux: (dev dm-3, type ext4) getxattr errno 34"

Seeing this error trying to mount ext4 disks. next-20180320 was OK. SELinux: (dev dm-3, type ext4) getxattr errno 34 and for /var, it refused to mount entirely (which brought the boot process to a screeching halt). git log shows commits in the past few days against both selinux and ext4, but

Re: [PATCH net-next 0/5] Introduce net_rwsem to protect net_namespace_list

From: Kirill Tkhai Date: Thu, 29 Mar 2018 19:20:23 +0300 > The series introduces fine grained rw_semaphore, which will be used > instead of rtnl_lock() to protect net_namespace_list. > > This improves scalability and allows to do non-exclusive sleepable > iteration

Re: [PATCH v2 2/2] libselinux: echo line number of bad label in selabel_fini()

Alright, then I'll resubmit with a fix for the compiler warnings and do the rest of the enhancements as a separate patch set. On Thu, Mar 29, 2018 at 12:35 PM, Stephen Smalley wrote: > On 03/29/2018 11:48 AM, Yuli Khodorkovskiy wrote: >> >> >> On Thu, Mar 29, 2018 at 9:49 AM,

[PATCH net-next 4/5] ovs: Remove rtnl_lock() from ovs_exit_net()

Here we iterate for_each_net() and removes vport from alive net to the exiting net. ovs_net::dps are protected by ovs_mutex(), and the others, who change it (ovs_dp_cmd_new(), __dp_destroy()) also take it. The same with datapath::ports list. So, we remove rtnl_lock() here. Signed-off-by: Kirill

[PATCH net-next 5/5] net: Remove rtnl_lock() in nf_ct_iterate_destroy()

rtnl_lock() doesn't protect net::ct::count, and it's not needed for__nf_ct_unconfirmed_destroy() and for nf_queue_nf_hook_drop(). Signed-off-by: Kirill Tkhai --- net/netfilter/nf_conntrack_core.c |2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH net-next 3/5] security: Remove rtnl_lock() in selinux_xfrm_notify_policyload()

rt_genid_bump_all() consists of ipv4 and ipv6 part. ipv4 part is incrementing of net::ipv4::rt_genid, and I see many places, where it's read without rtnl_lock(). ipv6 part calls __fib6_clean_all(), and it's also called without rtnl_lock() in other places. So, rtnl_lock() here was used to iterate

[PATCH net-next 2/5] net: Don't take rtnl_lock() in wireless_nlevent_flush()

This function iterates over net_namespace_list and flushes the queue for every of them. What does this rtnl_lock() protects?! Since we may add skbs to net::wext_nlevents without rtnl_lock(), it does not protects us about queuers. It guarantees, two threads can't flush the queue in parallel, that

Re: [PATCH v2 2/2] libselinux: echo line number of bad label in selabel_fini()

On 03/29/2018 11:48 AM, Yuli Khodorkovskiy wrote: > > > On Thu, Mar 29, 2018 at 9:49 AM, Stephen Smalley > wrote: > > On 03/28/2018 11:40 PM, Yuli Khodorkovskiy wrote: > > Keep track of line numbers for each file context in > >

Re: [PATCH v2 1/2] libselinux: verify file_contexts when using restorecon

On Thu, Mar 29, 2018 at 5:37 AM, Stephen Smalley wrote: > On 03/28/2018 11:40 PM, Yuli Khodorkovskiy wrote: >> In permissive mode, calling restorecon with a bad label in file_contexts >> does not verify the label's existence in the loaded policy. This >> results in any label

Re: [PATCH v2 2/2] libselinux: echo line number of bad label in selabel_fini()

On Thu, Mar 29, 2018 at 9:49 AM, Stephen Smalley wrote: > On 03/28/2018 11:40 PM, Yuli Khodorkovskiy wrote: > > Keep track of line numbers for each file context in > > selabel_handle. If an error occurs in selabel_fini(), the > > line number of an invalid file context is

Re: [PATCH v2 2/2] libselinux: echo line number of bad label in selabel_fini()

On 03/28/2018 11:40 PM, Yuli Khodorkovskiy wrote: > Keep track of line numbers for each file context in > selabel_handle. If an error occurs in selabel_fini(), the > line number of an invalid file context is echoed to the user. > > Signed-off-by: Yuli Khodorkovskiy > --- >

Re: [PATCH v2 1/2] libselinux: verify file_contexts when using restorecon

On 03/28/2018 11:40 PM, Yuli Khodorkovskiy wrote: > In permissive mode, calling restorecon with a bad label in file_contexts > does not verify the label's existence in the loaded policy. This > results in any label successfully applying to a file, as long as the > file exists. > > This issue has