xfs
[Top] [All Lists]

acl: Preserving the setuid/setgid/sticky bits

To: acl-devel@xxxxxxxxxx
Subject: acl: Preserving the setuid/setgid/sticky bits
From: Andreas Gruenbacher <agruen@xxxxxxx>
Date: Wed, 17 Jun 2009 14:46:07 +0200
Cc: xfs@xxxxxxxxxxx, Brandon Philips <brandon@xxxxxxxx>
Organization: SUSE Labs, Novell
Reply-to: acl-devel@xxxxxxxxxx
User-agent: KMail/1.10.3 (Linux/2.6.30-rc6-git3-4-pae; KDE/4.1.3; i686; ; )
Hello,

(Copying the xfs list for a wider audience while moving to the new list;
 please reply to acl-devel@xxxxxxxxxxx)

in a recent bug report, we found out that setfacl --restore sometimes destroys 
the suid/sgid bits. This has been fixed [1], but problem that setfacl
--restore cannot restore the setuid/setgid/sticky bits still remains: getfacl 
simply does not include this information in its output.

[1] Avoid unnecessary but destructive chown calls,
    http://git.savannah.gnu.org/cgit/acl.git/commit/?id=45833cc

Based on an earlier version from Brandon, I have created a patch which causes 
getfacl to include the special bits in its output, and setfacl to restore the 
bits when possible. The proposed format for special flags in the getfacl 
output would be:

        $ cd /
        $ getfacl bin/ping tmp
        # file: bin/ping
        # owner: root
        # group: root
        # flags: s--
        user::rwx
        group::r-x
        other::r-x

        # file: tmp
        # owner: root
        # group: root
        # flags: --t
        user::rwx
        group::rwx
        other::rwx

In the current version, getfacl only includes the new flags: comment for files 
which have any of the special set. Setfacl --restore clears all special bits 
if there is no flags: comment, and sets them accordingly otherwise. (Without 
--restore, setfacl disregards such comments, just like it disregards the other 
comments.)

Does this extension look reasonable?

Any objections to changing the behavior of --restore to clear the special 
flags in case there is no flags: comment? (And if so, wow would you like this 
solved instead?)

Thanks,
Andreas

Attachment: flags.diff
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>