First argument of matchpathcon_filespec_add

First argument of matchpathcon_filespec_add

[Yuichi Nakamura]

Hi,

We are porting SELinux commands to busybox with friends.
# Patch set will be released in near future..

In the process, we found problem in matchpathcon_filespec_add.

1) I tried to port setfiles.c to busybox. 
    I ran setfiles command from busybox, but it crashed in following(line 313): "matchpathcon_filespec_add".

   * setfiles.c
   307           * Try to add an association between this inode and
   308           * this specification.  If there is already an association
   309           * for this inode and it conflicts with this specification,
   310           * then use the last matching specification.
   311           */
   312          if (add_assoc) {
   313                  j = matchpathcon_filespec_add(my_sb.st_ino, i, my_file);
   314                  if (j < 0)
   315                          goto err;
   316
   317                  if (j != i) {
   318                          /* There was already an association and it took
precedence. */
   319                          goto out;


2) I found the reason why it crashed is size of mysb.st_ino is different between libselinux and busybox.

Prototype of matchpathcon_filespec_add is:
int matchpathcon_filespec_add(ino_t ino, int specind, const char *file)

The size of "ino_t" is diffenrent in busybox and libselinux.
Size of ino_t changes according to value of _FILE_OFFSET_BIT.
When libselinux is built, "-D_FILE_OFFSET_BIT=64" is defined.
However, in busybox "-D_FILE_OFFSET_BIT=64" is not defined, it depends on busybox configuration.

When we do not want to build busybox with -D_FILE_OFFSET_BIT=64,
we have to rebuild libselinux.

I think it is a problem.

Does anyone have good idea ?

--
Yuichi Nakamura

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: First argument of matchpathcon_filespec_add

[Russell Coker]

On Wednesday 29 November 2006 10:55, Yuichi Nakamura <ynakam@gwu.edu> wrote:
> When we do not want to build busybox with -D_FILE_OFFSET_BIT=64,
> we have to rebuild libselinux.
>
> I think it is a problem.
>
> Does anyone have good idea ?

What harm does it do to build busybox with 64bit file offsets?  For system 
recovery I think that 64bit offsets are desirable.

For embedded systems I guess you could have both the same whichever option you 
choose.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: First argument of matchpathcon_filespec_add

[KaiGai Kohei]

Russell Coker wrote:
> On Wednesday 29 November 2006 10:55, Yuichi Nakamura <ynakam@gwu.edu> wrote:
>> When we do not want to build busybox with -D_FILE_OFFSET_BIT=64,
>> we have to rebuild libselinux.
>>
>> I think it is a problem.
>>
>> Does anyone have good idea ?
> 
> What harm does it do to build busybox with 64bit file offsets?  For system 
> recovery I think that 64bit offsets are desirable.
> 
> For embedded systems I guess you could have both the same whichever option you 
> choose.

I think this topic should not be about the configuration of busybox,
be about the consistency of the libselinux interfaces.

Because the length of ino_t which is the first argument of the funciton
depends on the definition of _FILE_OFFSET_BIT, we have a possibility to
have different views on the interface of libselinux.
It is not limited in busybox cases.

Is it appropriate way that the consistency of libselinux's interface
depends on whether the application defines _FILE_OFFSET_BIT, or not?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: First argument of matchpathcon_filespec_add

[Stephen Smalley]

On Wed, 2006-11-29 at 21:14 +0900, KaiGai Kohei wrote:
> Russell Coker wrote:
> > On Wednesday 29 November 2006 10:55, Yuichi Nakamura <ynakam@gwu.edu> wrote:
> >> When we do not want to build busybox with -D_FILE_OFFSET_BIT=64,
> >> we have to rebuild libselinux.
> >>
> >> I think it is a problem.
> >>
> >> Does anyone have good idea ?
> > 
> > What harm does it do to build busybox with 64bit file offsets?  For system 
> > recovery I think that 64bit offsets are desirable.
> > 
> > For embedded systems I guess you could have both the same whichever option you 
> > choose.
> 
> I think this topic should not be about the configuration of busybox,
> be about the consistency of the libselinux interfaces.
> 
> Because the length of ino_t which is the first argument of the funciton
> depends on the definition of _FILE_OFFSET_BIT, we have a possibility to
> have different views on the interface of libselinux.
> It is not limited in busybox cases.
> 
> Is it appropriate way that the consistency of libselinux's interface
> depends on whether the application defines _FILE_OFFSET_BIT, or not?

I agree that it is a problem with the interface.  We could attempt to
address it in a similar manner to stat() handling, but the interface is
likely to become obsolete once the new label lookup interfaces being
proposed by Eamon Walsh are adopted and setfiles is converted over to
using them.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: First argument of matchpathcon_filespec_add

[Eamon Walsh]

On Wed, 2006-11-29 at 10:10 -0500, Stephen Smalley wrote:
> I agree that it is a problem with the interface.  We could attempt to
> address it in a similar manner to stat() handling, but the interface is
> likely to become obsolete once the new label lookup interfaces being
> proposed by Eamon Walsh are adopted and setfiles is converted over to
> using them.

That's correct, the new interface will not take the mode but instead a
security class, such as chr_file, blk_file, etc.

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: First argument of matchpathcon_filespec_add

[Yuichi Nakamura]

----- Original Message -----
> On Wed, 2006-11-29 at 10:10 -0500, Stephen Smalley wrote:
> > I agree that it is a problem with the interface.  We could attempt to
> > address it in a similar manner to stat() handling, but the interface 
> is
> > likely to become obsolete once the new label lookup interfaces being
> > proposed by Eamon Walsh are adopted and setfiles is converted over to
> > using them.
> 
> That's correct, the new interface will not take the mode but instead a
> security class, such as chr_file, blk_file, etc.

Thanks for reply.
I will solve the problem by defining _FILE_OFFSET_BIT 64 only in setfiles.c
until new setfiles implementation appears.

Yuichi Nakamura

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.