[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#270101: marked as done (Please support setuid/setgid in ACLs)

Your message dated Sun, 9 Aug 2009 13:53:00 +0200
with message-id <20090809115300.GA15801@galadriel.inutil.org>
and subject line Re: Please support setuid/setgid in ACLs
has caused the Debian Bug report #270101,
regarding Please support setuid/setgid in ACLs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
270101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270101
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: acl
Version: 2.2.23-1
Severity: wishlist

Hi,

imagine the following scenario: you have a binary that you wish group A to
be able to execute, and group B to be able to execute setuid.

This can't currently be done; if the binary is setuid, you can make it
executable by group B only, in which case group B will have setuid execute
access, but group A will have no access.

Similar problems arise when trying to grant selective access to the setgid
bit (and the sticky bit, but that doesn't seem useful in this context).

Effectively, I'd like to be able to say something like:

setfacl -m g:somegroup:rwu binary # for setuid
setfacl -m g:somegroup:rwg binary # for setgid
setfacl -m g:somegroup:rws binary # for setuid and setgid
setfacl -m g:somegroup:rwU binary # for setuid but no execute
setfacl -m g:somegroup:rwG binary # for setgid but no execute
setfacl -m g:somegroup:rwS binary # for setuid and setgid but no execute

Obviously, other notations would be possible and perhaps more practical.

I realize this is hard to do because quite a bit of the infrastructure would
have to be changed to implement the semantics.

I also realize the Debian BTS may not be the best place to file this report;
my primary motivation now is to have this written down so that it can catch
the eye of someone willing to work on it.

Best regards,

Andras

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-chardonnay
Locale: LANG=C, LC_CTYPE=hu_HU

Versions of packages acl depends on:
ii  libacl1                     2.2.23-1     Access control list shared library
ii  libattr1                    2.4.16-1     Extended attribute shared library
ii  libc6                       2.3.2.ds1-16 GNU C Library: Shared libraries an

-- no debconf information

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
             Time is a great teacher, but it kills all its pupils.

--- End Message ---
--- Begin Message --- 
On Sun, Sep 05, 2004 at 03:18:30PM +0200, Andras Korn wrote:
> Package: acl
> Version: 2.2.23-1
> Severity: wishlist
> 
> Hi,
> 
> imagine the following scenario: you have a binary that you wish group A to
> be able to execute, and group B to be able to execute setuid.
> 
> This can't currently be done; if the binary is setuid, you can make it
> executable by group B only, in which case group B will have setuid execute
> access, but group A will have no access.
> 
> Similar problems arise when trying to grant selective access to the setgid
> bit (and the sticky bit, but that doesn't seem useful in this context).
> 
> Effectively, I'd like to be able to say something like:
> 
> setfacl -m g:somegroup:rwu binary # for setuid
> setfacl -m g:somegroup:rwg binary # for setgid
> setfacl -m g:somegroup:rws binary # for setuid and setgid
> setfacl -m g:somegroup:rwU binary # for setuid but no execute
> setfacl -m g:somegroup:rwG binary # for setgid but no execute
> setfacl -m g:somegroup:rwS binary # for setuid and setgid but no execute
> 
> Obviously, other notations would be possible and perhaps more practical.
> 
> I realize this is hard to do because quite a bit of the infrastructure would
> have to be changed to implement the semantics.
> 
> I also realize the Debian BTS may not be the best place to file this report;
> my primary motivation now is to have this written down so that it can catch
> the eye of someone willing to work on it.

The Debian BTS in fact isn't the best place. Our policy is too stay close
to the upstream kernels. If you want to have this changed, please start a
discussion on the kernel development mailing list: linux-kernel@vger.kernel.org 

Cheers,
        Moritz

--- End Message ---
Reply to: