Re: [lmi] Should 'chmod g=u' remove the 's' in "drwxrws"?

[Vadim Zeitlin]

On Tue, 17 Mar 2020 22:14:39 +0000 Greg Chicares <address@hidden> wrote:

GC> 'chmod g+s' is not undone by a subsequent 'chmod g=u', at least
GC> not with debian testing:
GC> 
GC> /tmp/eraseme[0]$mkdir --parents foo/bar              
GC> /tmp/eraseme[0]$ls -l foo
GC> total 4
GC> drwxr-xr-x 2 greg greg 4096 Mar 17 22:04 bar
GC> /tmp/eraseme[0]$chmod g+s foo/bar
GC> /tmp/eraseme[0]$ls -l foo        
GC> total 4
GC> drwxr-sr-x 2 greg greg 4096 Mar 17 22:04 bar
GC> /tmp/eraseme[0]$chmod g=u foo/bar      
GC> /tmp/eraseme[0]$ls -l foo        
GC> total 4
GC> drwxrwsr-x 2 greg greg 4096 Mar 17 22:04 bar
GC> 
GC> But why not?

 I can't answer the question "why"...

GC> This is a nice behavior, but I can't find it documented on
GC> the GNU/Linux manpage or in the gnu coreutils manual,

 ... but I can point to a place where it is documented, see 

https://manpages.debian.org/buster/coreutils/chmod.1.en.html#SETUID_AND_SETGID_BITS

 Quoting from there

        For directories chmod preserves set-user-ID and set-group-ID bits
        unless you explicitly specify otherwise. You can set or clear the
        bits with symbolic modes like u+s and g-s. To clear these bits for
        directories with a numeric mode requires an additional leading
        zero, or leading = like 00755 , or =755

GC> so can I safely rely upon it?

 I'm also not really sure about this, as e.g. FreeBSD chmod manual page at

        https://www.freebsd.org/cgi/man.cgi?query=chmod

doesn't mention any such exceptions. It doesn't mean it doesn't work like
this there, of course, it might just be undocumented.

 But I think it's safe to assume that all GNU/Linux systems and maybe even
all systems using GNU coreutils do behave like this, which could be good
enough for lmi.

 Regards,
VZ

pgpZGu5vMcpPl.pgp
Description: PGP signature