linux-next: manual merge of the lblnet tree

linux-next: manual merge of the lblnet tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the lblnet tree got a conflicts in
security/smack/smack_lsm.c and security/smack/smackfs.c between commits
86a264abe542cfececb4df129bc45a0338d8cdb9 ("CRED: Wrap current->cred and a
few other accessors") and d84f4f992cbd76e8f39c488cf0c5d123843923b1
("CRED: Inaugurate COW credentials") from the security-testing tree and
commit d936691ab765fbac809e9a05c7f0c36ce2c2119e ("smack: Add support for
unlabeled network hosts and networks") from the lblnet tree.

I fixed it up (see below) and can carry the fixes as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc security/smack/smack_lsm.c
index 8ad4816,06471e8..0000000
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@@ -2100,11 -2181,13 +2226,17 @@@ static int smack_setprocattr(struct tas
  	if (newsmack == NULL)
  		return -EINVAL;
  
+ 	/*
+ 	 * No process is ever allowed the web ("@") label.
+ 	 */
+ 	if (newsmack == smack_known_web.smk_known)
+ 		return -EPERM;
+ 
 -	p->security = newsmack;
 +	new = prepare_creds();
 +	if (!new)
 +		return -ENOMEM;
 +	new->security = newsmack;
 +	commit_creds(new);
  	return size;
  }
  
@@@ -2337,10 -2488,11 +2537,10 @@@ static void smack_sock_graft(struct soc
  		return;
  
  	ssp = sk->sk_security;
 -	ssp->smk_in = current->security;
 -	ssp->smk_out = current->security;
 +	ssp->smk_in = ssp->smk_out = current_security();
  	ssp->smk_packet[0] = '\0';
  
- 	rc = smack_netlabel(sk);
+ 	rc = smack_netlabel(sk, SMACK_CIPSO_SOCKET);
  	if (rc != 0)
  		printk(KERN_WARNING "Smack: \"%s\" netlbl error %d.\n",
  		       __func__, -rc);
diff --cc security/smack/smackfs.c
index ca257df,a75013f..0000000
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@@ -104,6 -107,24 +107,24 @@@ struct smk_list_entry *smack_list
  #define SMK_ACCESSLEN (sizeof(SMK_ACCESS) - 1)
  #define SMK_LOADLEN   (SMK_LABELLEN + SMK_LABELLEN + SMK_ACCESSLEN)
  
+ /**
+  * smk_netlabel_audit_set - fill a netlbl_audit struct
+  * @nap: structure to fill
+  */
+ static void smk_netlabel_audit_set(struct netlbl_audit *nap)
+ {
+ 	nap->loginuid = audit_get_loginuid(current);
+ 	nap->sessionid = audit_get_sessionid(current);
 -	nap->secid = smack_to_secid(current->security);
++	nap->secid = smack_to_secid(current_security());
+ }
+ 
+ /*
+  * Values for parsing single label host rules
+  * "1.2.3.4 X"
+  * "192.168.138.129/32 abcdefghijklmnopqrstuvw"
+  */
+ #define SMK_NETLBLADDRMIN	9
+ #define SMK_NETLBLADDRMAX	42
  
  /*
   * Seq_file read operations for /smack/load

Re: linux-next: manual merge of the lblnet tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Today's linux-next merge of the lblnet tree got a conflicts in
> security/smack/smack_lsm.c and security/smack/smackfs.c between commits
> 86a264abe542cfececb4df129bc45a0338d8cdb9 ("CRED: Wrap current->cred and a
> few other accessors") and d84f4f992cbd76e8f39c488cf0c5d123843923b1
> ("CRED: Inaugurate COW credentials") from the security-testing tree and
> commit d936691ab765fbac809e9a05c7f0c36ce2c2119e ("smack: Add support for
> unlabeled network hosts and networks") from the lblnet tree.
> 
> I fixed it up (see below) and can carry the fixes as necessary.

That looks reasonable, I think.

David

Re: linux-next: manual merge of the lblnet tree

[Casey Schaufler]

Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the lblnet tree got a conflicts in
> security/smack/smack_lsm.c and security/smack/smackfs.c between commits
> 86a264abe542cfececb4df129bc45a0338d8cdb9 ("CRED: Wrap current->cred and a
> few other accessors") and d84f4f992cbd76e8f39c488cf0c5d123843923b1
> ("CRED: Inaugurate COW credentials") from the security-testing tree and
> commit d936691ab765fbac809e9a05c7f0c36ce2c2119e ("smack: Add support for
> unlabeled network hosts and networks") from the lblnet tree.
>
> I fixed it up (see below) and can carry the fixes as necessary.
>   
I don't see any problems with the changes. Thank you.

Re: linux-next: manual merge of the lblnet tree

[Paul Moore]

On Monday 08 December 2008 3:07:08 am Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the lblnet tree got a conflicts in
> security/smack/smack_lsm.c and security/smack/smackfs.c between
> commits 86a264abe542cfececb4df129bc45a0338d8cdb9 ("CRED: Wrap
> current->cred and a few other accessors") and
> d84f4f992cbd76e8f39c488cf0c5d123843923b1 ("CRED: Inaugurate COW
> credentials") from the security-testing tree and commit
> d936691ab765fbac809e9a05c7f0c36ce2c2119e ("smack: Add support for
> unlabeled network hosts and networks") from the lblnet tree.
>
> I fixed it up (see below) and can carry the fixes as necessary.

Thanks Stephen.  It sounds like both David and Casey are okay with the 
changes so I have no arguments with the fix-up patch.

James, is the security-testing tree rebased regularly or is suitable to 
back a tree against?  If so, I can rebase the lblnet-2.6_next tree 
against security-testing to resolve the conflict ...

-- 
paul moore
linux @ hp

Re: linux-next: manual merge of the lblnet tree

[James Morris]

On Mon, 8 Dec 2008, Paul Moore wrote:

> James, is the security-testing tree rebased regularly or is suitable to 
> back a tree against?

No, it doesn't get rebased.

>  If so, I can rebase the lblnet-2.6_next tree 
> against security-testing to resolve the conflict ...

Ok, and I can carry your patches in there if necessary.


-- 
James Morris
<jmorris@namei.org>

Re: linux-next: manual merge of the lblnet tree

[Paul Moore]

On Monday 08 December 2008 4:16:24 pm James Morris wrote:
> On Mon, 8 Dec 2008, Paul Moore wrote:
> > James, is the security-testing tree rebased regularly or is
> > suitable to back a tree against?
>
> No, it doesn't get rebased.

Okay, experiment time.  I think I managed to pull from all the right 
spots, merge everything appropriately and end up with a security/ 
directory that builds so I pushed it back out to the lblnet-2.6_next 
tree.  I'm not quite sure the proper etiquette here but I had to fix 
Casey's patch a bit since it would apply cleanly; Casey if you could 
take a look I would appreciate it (it isn't exactly like what Stephen 
posted earlier but it is pretty darn close).

> >  If so, I can rebase the lblnet-2.6_next tree
> > against security-testing to resolve the conflict ...
>
> Ok, and I can carry your patches in there if necessary.

I would like to figure out to make this work as it is likely to happen 
again at some point in the future, but if I can't get it working 
quickly I may punt on it and ask you to pull in the patches.

-- 
paul moore
linux @ hp

Re: linux-next: manual merge of the lblnet tree

[Casey Schaufler]

Paul Moore wrote:
> On Monday 08 December 2008 4:16:24 pm James Morris wrote:
>   
>> On Mon, 8 Dec 2008, Paul Moore wrote:
>>     
>>> James, is the security-testing tree rebased regularly or is
>>> suitable to back a tree against?
>>>       
>> No, it doesn't get rebased.
>>     
>
> Okay, experiment time.  I think I managed to pull from all the right 
> spots, merge everything appropriately and end up with a security/ 
> directory that builds so I pushed it back out to the lblnet-2.6_next 
> tree.  I'm not quite sure the proper etiquette here but I had to fix 
> Casey's patch a bit since it would apply cleanly; Casey if you could 
> take a look I would appreciate it (it isn't exactly like what Stephen 
> posted earlier but it is pretty darn close).
>   

\Working ...

Re: linux-next: manual merge of the lblnet tree

[Casey Schaufler]

Paul Moore wrote:
> On Monday 08 December 2008 4:16:24 pm James Morris wrote:
>   
>> On Mon, 8 Dec 2008, Paul Moore wrote:
>>     
>>> James, is the security-testing tree rebased regularly or is
>>> suitable to back a tree against?
>>>       
>> No, it doesn't get rebased.
>>     
>
> Okay, experiment time.  I think I managed to pull from all the right 
> spots, merge everything appropriately and end up with a security/ 
> directory that builds so I pushed it back out to the lblnet-2.6_next 
> tree.  I'm not quite sure the proper etiquette here but I had to fix 
> Casey's patch a bit since it would apply cleanly; Casey if you could 
> take a look I would appreciate it (it isn't exactly like what Stephen 
> posted earlier but it is pretty darn close).
>
>   

The Smack Verification Laboratory reports that lblnet-2.6_next is
working as expected for UDP and TCP.

>>>  If so, I can rebase the lblnet-2.6_next tree
>>> against security-testing to resolve the conflict ...
>>>       
>> Ok, and I can carry your patches in there if necessary.
>>     
>
> I would like to figure out to make this work as it is likely to happen 
> again at some point in the future, but if I can't get it working 
> quickly I may punt on it and ask you to pull in the patches.
>
>   

Re: linux-next: manual merge of the lblnet tree

[Paul Moore]

On Wednesday 10 December 2008 12:05:44 pm Casey Schaufler wrote:
> Paul Moore wrote:
> > On Monday 08 December 2008 4:16:24 pm James Morris wrote:
> >> On Mon, 8 Dec 2008, Paul Moore wrote:
> >>> James, is the security-testing tree rebased regularly or is
> >>> suitable to back a tree against?
> >>
> >> No, it doesn't get rebased.
> >
> > Okay, experiment time.  I think I managed to pull from all the
> > right spots, merge everything appropriately and end up with a
> > security/ directory that builds so I pushed it back out to the
> > lblnet-2.6_next tree.  I'm not quite sure the proper etiquette here
> > but I had to fix Casey's patch a bit since it would apply cleanly;
> > Casey if you could take a look I would appreciate it (it isn't
> > exactly like what Stephen posted earlier but it is pretty darn
> > close).
>
> The Smack Verification Laboratory reports that lblnet-2.6_next is
> working as expected for UDP and TCP.

Sounds expensive :)  Thanks for checking, assuming no problems I'll push 
those patches with the rest of the labeled networking patches when the 
next merge window opens.

-- 
paul moore
linux @ hp

linux-next: manual merge of the lblnet tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the lblnet tree got a conflict in
Documentation/feature-removal-schedule.txt between commit
839361440c4cf848dddc5705fa4ac7c25d00dddf ("hwmon: Deprecate the fscher
and fscpos drivers") from the jdelvare-hwmon tree and commit
d45075ffb96a78c0f7137cfcec9fe816a6d23cfb ("selinux: Deprecate and
schedule the removal of the the compat_net functionality") from the
lblnet tree.

Just overlapping additions.  I fixed it up (see below) and can carry it
as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc Documentation/feature-removal-schedule.txt
index ba66f38,6ae3e9b..0000000
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@@ -339,8 -346,12 +339,20 @@@ Who:	Jean Delvare <khali@linux-fr.org
  
  ---------------------------
  
 +What:	fscher and fscpos drivers
 +When:	June 2009
 +Why:	Deprecated by the new fschmd driver.
 +Who:	Hans de Goede <hdegoede@redhat.com>
 +	Jean Delvare <khali@linux-fr.org>
++
++---------------------------
++
+ What:	SELinux "compat_net" functionality
+ When:	2.6.30 at the earliest
+ Why:	In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
+ 	network access control functionality of SELinux.  Secmark offers both
+ 	better performance and greater flexibility than the "compat_net"
+ 	mechanism.  Now that the major Linux distributions have moved to
+ 	Secmark, it is time to deprecate the older mechanism and start the
+ 	process of removing the old code.
+ Who:	Paul Moore <paul.moore@hp.com>

Re: linux-next: manual merge of the lblnet tree

[Paul Moore]

On Monday 08 December 2008 2:49:57 am Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the lblnet tree got a conflict in
> Documentation/feature-removal-schedule.txt between commit
> 839361440c4cf848dddc5705fa4ac7c25d00dddf ("hwmon: Deprecate the
> fscher and fscpos drivers") from the jdelvare-hwmon tree and commit
> d45075ffb96a78c0f7137cfcec9fe816a6d23cfb ("selinux: Deprecate and
> schedule the removal of the the compat_net functionality") from the
> lblnet tree.
>
> Just overlapping additions.  I fixed it up (see below) and can carry
> it as necessary.

Thanks.  Other than pulling in the jdelvare-hwmon tree or moving the 
entry somewhere else in the file (not solving anything, just 
moving/delaying the problem) I'm not sure how to resolve the conflict.  
If you don't mind carrying your fix-up patch until the merge window 
opens that sounds like the best approach to me.

-- 
paul moore
linux @ hp

Re: linux-next: manual merge of the lblnet tree

[Jean Delvare]

On Mon, 8 Dec 2008 14:38:04 -0500, Paul Moore wrote:
> On Monday 08 December 2008 2:49:57 am Stephen Rothwell wrote:
> > Hi Paul,
> >
> > Today's linux-next merge of the lblnet tree got a conflict in
> > Documentation/feature-removal-schedule.txt between commit
> > 839361440c4cf848dddc5705fa4ac7c25d00dddf ("hwmon: Deprecate the
> > fscher and fscpos drivers") from the jdelvare-hwmon tree and commit
> > d45075ffb96a78c0f7137cfcec9fe816a6d23cfb ("selinux: Deprecate and
> > schedule the removal of the the compat_net functionality") from the
> > lblnet tree.
> >
> > Just overlapping additions.  I fixed it up (see below) and can carry
> > it as necessary.
> 
> Thanks.  Other than pulling in the jdelvare-hwmon tree or moving the 
> entry somewhere else in the file (not solving anything, just 
> moving/delaying the problem) I'm not sure how to resolve the conflict.  
> If you don't mind carrying your fix-up patch until the merge window 
> opens that sounds like the best approach to me.

All in all I don't think it really matters.
Documentation/feature-removal-schedule.txt will always have conflicts
by design, but it's only a text file and if it isn't totally up-to-date
in linux-next, I doubt anybody cares. So I would vote for permanently
ignoring conflicts to this file.

-- 
Jean Delvare

Re: linux-next: manual merge of the lblnet tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi Jean,

On Mon, 8 Dec 2008 21:19:41 +0100 Jean Delvare <khali@linux-fr.org> wrote:
>
> All in all I don't think it really matters.
> Documentation/feature-removal-schedule.txt will always have conflicts
> by design, but it's only a text file and if it isn't totally up-to-date
> in linux-next, I doubt anybody cares. So I would vote for permanently
> ignoring conflicts to this file.

I still have to do something with the conflicts and fixing them (like
this one) is trivial and "git rerere" remembers them, so carrying them is
also trivial.  And, as you imply, it really doesn't matter if I get one
wrong. :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]