public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sven Joachim <svenjoac@gmx.de>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Guillem Jover <guillem@hadrons.org>
Subject: Re: [PATCH 1/2] builddeb: Fix rootless build in setuid/setgid directory
Date: Wed, 28 Oct 2020 19:30:23 +0100	[thread overview]
Message-ID: <871rhi19vk.fsf@turtle.gmx.de> (raw)
In-Reply-To: <CAK7LNAS4VfYLLBZn=Fkd+D5D+3ejVd4jPFLtWu6joLxVXtxKUg@mail.gmail.com> (Masahiro Yamada's message of "Wed, 28 Oct 2020 15:00:22 +0900")

On 2020-10-28 15:00 +0900, Masahiro Yamada wrote:

> On Tue, Oct 27, 2020 at 4:32 AM Sven Joachim <svenjoac@gmx.de> wrote:
>>
>> Building 5.10-rc1 in a setgid directory failed with the following
>> error:
>>
>> dpkg-deb: error: control directory has bad permissions 2755 (must be
>> >=0755 and <=0775)
>>
>> When building with fakeroot, the earlier chown call would have removed
>> the setgid bits, but in a rootless build they remain.
>>
>
>
> Applied to linux-kbuild. Thanks.

I don't see it there, have you pushed it out yet?

> I agreed with "g-s" but was not sure about "u-s"
> because nothing is explained about setuid,
> and the setuid bit against directories seems to have no effect.
>
>
>
>
>
> It was interesting to read this article:
> https://superuser.com/questions/471844/why-is-setuid-ignored-on-directories
>
>
>
> Also, it is summarized in the wikipedia
> https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
>
> "The setuid permission set on a directory is ignored on most UNIX and
> Linux systems.[citation needed] However FreeBSD can be configured to
> interpret setuid in a manner similar to setgid, in which case it
> forces all files and sub-directories created in a directory to be
> owned by that directory's owner - a simple form of inheritance.[5]
> This is generally not needed on most systems derived from BSD, since
> by default directories are treated as if their setgid bit is always
> set, regardless of the actual value. As is stated in open(2), "When a
> new file is created it is given the group of the directory which
> contains it.""
>
>
> After all, I am convinced that it would not hurt to do "u-s"
> although I have never tested kernel builds on FreeBSD.

Agreed, setuid directories should not end up in the .deb files even if
that bit does currently nothing.

Cheers,
       Sven

      reply	other threads:[~2020-10-29  0:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 19:32 [PATCH 1/2] builddeb: Fix rootless build in setuid/setgid directory Sven Joachim
2020-10-26 19:32 ` [PATCH 2/2] builddeb: Consolidate consecutive chmod calls into one Sven Joachim
2020-10-28  6:52   ` Masahiro Yamada
2020-10-29 15:39     ` [PATCH] " Sven Joachim
2020-10-28  6:00 ` [PATCH 1/2] builddeb: Fix rootless build in setuid/setgid directory Masahiro Yamada
2020-10-28 18:30   ` Sven Joachim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rhi19vk.fsf@turtle.gmx.de \
    --to=svenjoac@gmx.de \
    --cc=guillem@hadrons.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox