Re: Bug in how capability inheritance is handled in "fs/exec.c", 2.3.99

From: Theodore Y. Ts'o (tytso@MIT.EDU)
Date: Thu Jun 01 2000 - 07:25:40 EST

[ I've directed follow ups to the linux-privs mailing list, to try to
  avoid the load on the linux-kernel mailing list. Please respect the
  reply-to header. Also, please note that I'm about to move the
  linux-privs mailing list to
  over the next day or so. Linux-privs subscribers will be
  automatically subscribed to the new list, and will
  change to a forwarding pointer pointing at the list.
  Since I'm no longer at MIT, and allows automatic
  list management and archival, this seems to make a lot of sense. ]

   Date: Wed, 31 May 2000 17:38:59 -0700
   From: Casey Schaufler <>

   "Theodore Y. Ts'o" wrote:

> On of the problems is that the draft doesn't state how the bits
> would typically get used. For example, what would the PIE permissions
> be on a typical system after login is run?

   For your normal user (let's call him Albert) the capset would be
   empty, in Irix terms "all=".

Oh, good! That's what I thought; we're not that far apart after all.
It's however not what Linda was stating in her e-mail messages, where
she seems to assert that untrusted users get an I capset of ~0, and that
some uid's might have additional bits set in the P and I capsets:

>'s said on Mon, 29 May 2000 12:47:40 -0700
> login, running with PIE=(all,all,all) now wants to "log in"
>user 'backup'. It forks and sets PIE=(01,all,01) (using 01 for
>DAC_READ_SEARCH). This works. So pPIE=(01,all,01)

Does Trusted Irix really work this way?!?

   If we want Albert to perform some particular function we might give
   him access to some capabilities, which he could get as needed with
   "su -C", based on his entry in /etc/capability. It is important to
   understand that a capability set doth not a role define, and trying
   to make it so is a road to madness.

I certainly agree with your last statement. But you should check and
see what Linda's claims for how capabilities should work. Her claim is
that the backup uid get DAC_READ_SEARCH if you login with that uid,
which certainly sounds like using a capability set as a role-based
mechanism. When this didn't work correctly based the way Linux
implemented things, she claimed this proved that our current mechanism
was broken. I tend to agree with you that it leads to madness.

This confusion about exactly how things are supposed to work really
leads me to believe a face-to-face meeting would be helpful. I've
gotten authorization to host a quick (informal and on short-notice)
meeting at VA while I'm in town in Sunnyvale. Given that some of the
interested parties (SGI folks, Andrew Morgan, myself) will be in the Bay
Area then, it might make sense to try to hash out these issues
in-person and on a white-board. I was thinking perhaps a Friday
afternoon on the June 16th, perhaps? That would be most convenient for
me, but perhaps not for others. Comments?

                                                - Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:12 EST