• Restricting who can run a set-user-id-root executable

    From Noob@21:1/5 to All on Sat Oct 30 17:04:48 2021
    Hello,

    (It's been an exceedingly long time since I last posted here. Happy to be back)

    I've written my first Linux set-user-id-root program (let's call it foo-bin)

    foo-bin is suid-root because:
    1) foo-bin is supposed to be run by an unprivileged user,
    2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

    I didn't want *every* unprivileged user to be able to run foo-bin.
    Only user 12345 is allowed to run foo-bin.

    So I just added trivial code at the start of foo-bin:

    if (getuid() != 12345)
    die("Bad credentials");

    My understanding is that, for an executable with the suid-root bit set,
    the process's effective-user-id and saved-user-id will be 0 (root) while the real-user-id (returned by getuid) will be that of the user running the program.

    Thus my two-line "fix" seemed (seems?) like a perfect solution...
    Yet, I didn't find anyone suggesting it on the interwebz, so I figured
    it's just too simple to be correct.

    I know there are things like dynamic library preloading that might allow
    one to change getuid() to a no-op. (Though I'm aware that Linux ignores
    dynamic library preloading for suid-root, probably for that reason.)

    Could you point out how/why the proposed solution breaks/falls apart?


    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    Thus:
    1) "random" normal users are not allowed to run foo-bin
    2) user12345 is the only unprivileged user allowed to run foo-bin

    Perhaps this solution is safer/better than my first solution?

    Happy to read all your comments ;)

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Noob on Sat Oct 30 20:52:02 2021
    Noob <root@127.0.0.1> writes:

    I've written my first Linux set-user-id-root program (let's call it foo-bin)

    foo-bin is suid-root because:
    1) foo-bin is supposed to be run by an unprivileged user,
    2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

    I didn't want *every* unprivileged user to be able to run foo-bin.
    Only user 12345 is allowed to run foo-bin.

    So I just added trivial code at the start of foo-bin:

    if (getuid() != 12345)
    die("Bad credentials");

    Generally, this sort of thing is done using sudo rather than hard-wiring
    UIDs into source code. That sets my (code) teeth on edge!

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to root@127.0.0.1 on Sat Oct 30 20:37:41 2021
    In article <sljmug$8di$2@dont-email.me>, Noob <root@127.0.0.1> wrote:
    ...
    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    My first (and best) thought was to do it via grops. Seems tailor-made for this.

    I'd create a new group (Say, foo-bin-users) and add your user to that
    group. This makes it easy to add others in the future.

    --
    The single most important statistic in the US today - the one that explains all the
    others - is this: 63 million people thought it was a good idea to vote for this clown
    (and will probably do so again). Everything else is secondary to that. Everything else
    could be fixed if we can revert this one statistic. Nothing can be fixed until we do.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James K. Lowden@21:1/5 to Noob on Sat Oct 30 17:08:46 2021
    On Sat, 30 Oct 2021 17:04:48 +0200
    Noob <root@127.0.0.1> wrote:

    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)


    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    --jkl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Keith Thompson on Sat Oct 30 23:43:12 2021
    On 30/10/2021 23:20, Keith Thompson wrote:

    "James K. Lowden" writes:

    Noob wrote:

    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    Hmm? 4640 means no execute permission for anyone.

    And since the original requirement was to allow only one *user*
    to execute it, I'm not sure why everyone is talking about group
    permissions. I'd make it 4700 or 4500 and set its ownership to
    the one user who's allowed to execute it.

    Original requirement was to allow only one user to execute foo-bin *as root*

    Therefore, foo-bin must be owned by root :)

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to James K. Lowden on Sat Oct 30 14:20:54 2021
    "James K. Lowden" <jklowden@speakeasy.net> writes:
    On Sat, 30 Oct 2021 17:04:48 +0200
    Noob <root@127.0.0.1> wrote:

    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)


    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    Hmm? 4640 means no execute permission for anyone.

    And since the original requirement was to allow only one *user*
    to execute it, I'm not sure why everyone is talking about group
    permissions. I'd make it 4700 or 4500 and set its ownership to
    the one user who's allowed to execute it.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to James K. Lowden on Sat Oct 30 21:18:07 2021
    In article <20211030170846.ef437b362217cf4a4614936e@speakeasy.net>,
    James K. Lowden <jklowden@speakeasy.net> wrote:
    On Sat, 30 Oct 2021 17:04:48 +0200
    Noob <root@127.0.0.1> wrote:

    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)


    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    No. 755 is normal for executable files. You could get away with 711.

    Actually, a habit I got into lomg ago, which has served me well over the
    years, is to do: chmod 4711 ...

    whenever I want to make something setuid (root).

    So, if you're going to do the "group thing", it would be 4710.

    --
    The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
    http://user.xmission.com/~gazelle/Sigs/Seriously

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Kenny McCormack on Sat Oct 30 23:47:10 2021
    On 30/10/2021 22:37, Kenny McCormack wrote:

    In article <sljmug$8di$2@dont-email.me>, Noob wrote:
    ...
    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    My first (and best) thought was to do it via grops. Seems tailor-made for this.

    s/grops/groups ? (I first parsed that as "grope", then gr_ops)

    If groups, then you are agreeing with me, right?

    I'd create a new group (Say, foo-bin-users) and add your user to that
    group. This makes it easy to add others in the future.

    I understand your point.

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to James K. Lowden on Sat Oct 30 23:51:28 2021
    On 30/10/2021 23:08, James K. Lowden wrote:

    Noob wrote:

    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    Your suggestion must be a typo/thinko?

    Execute bit is 1. So none of 6,4,0 have the execute bit set.
    Which is a problem for an executable :)

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John McCue@21:1/5 to Kenny McCormack on Sat Oct 30 23:23:10 2021
    Kenny McCormack <gazelle@shell.xmission.com> wrote:
    In article <sljmug$8di$2@dont-email.me>, Noob <root@127.0.0.1> wrote:
    ...
    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    My first (and best) thought was to do it via grops. Seems tailor-made for this.

    I'd create a new group (Say, foo-bin-users) and add your user to that
    group. This makes it easy to add others in the future.

    That was what I thought too, then I realized may be better
    to not bother with getuid(2) getgid(2) and just do:

    # chgrp foo-bin
    # chmod 750 foo-bin

    Then it is not tied to a specific hard-coded ID/Group
    and no setgid needed

    --
    csh(1) - "An elegant shell, for a more... civilized age."
    - Paraphrasing Star Wars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James K. Lowden@21:1/5 to Noob on Sat Oct 30 21:07:40 2021
    On Sat, 30 Oct 2021 23:51:28 +0200
    Noob <root@127.0.0.1> wrote:

    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    Your suggestion must be a typo/thinko?

    Yah. More coffee and less scotch, I guess. Or the opposite.

    --jkl

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Noob on Sat Oct 30 23:48:32 2021
    Noob <root@127.0.0.1> writes:
    On 30/10/2021 23:20, Keith Thompson wrote:
    "James K. Lowden" writes:
    Noob wrote:
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    Don't you mean 4640? 0644 is typical for binaries. You're removing
    world access and adding set-user-ID.

    Hmm? 4640 means no execute permission for anyone.

    And since the original requirement was to allow only one *user*
    to execute it, I'm not sure why everyone is talking about group
    permissions. I'd make it 4700 or 4500 and set its ownership to
    the one user who's allowed to execute it.

    Original requirement was to allow only one user to execute foo-bin *as root*

    Therefore, foo-bin must be owned by root :)

    Oops, you're right.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Ben Bacarisse on Sun Oct 31 10:55:53 2021
    On 30/10/2021 21:52, Ben Bacarisse wrote:

    Noob writes:

    I've written my first Linux set-user-id-root program (let's call it foo-bin) >>
    foo-bin is suid-root because:
    1) foo-bin is supposed to be run by an unprivileged user,
    2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups) >>
    I didn't want *every* unprivileged user to be able to run foo-bin.
    Only user 12345 is allowed to run foo-bin.

    So I just added trivial code at the start of foo-bin:

    if (getuid() != 12345)
    die("Bad credentials");

    Generally, this sort of thing is done using sudo rather than hard-wiring
    UIDs into source code. That sets my (code) teeth on edge!

    Indeed, my solution above doesn't feel "right", I'll grant you that.

    (It's worth noting that I work on an embedded system, where there are no
    "real" users. User IDs are just used to isolate binaries from each other.)

    In your solution, how would your sudo suggestion work?
    You would add user12345 to the sudoers group?
    But then user12345 could do anything that root can.
    I want user12345 to be able to run foo-bin as root, nothing more.

    Do you see any security issue with my solution #1?
    I'll adopt solution #2 in production, but I wanted to hear people's opinion
    as to why solution #1 fails ;)

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to John McCue on Sun Oct 31 10:48:19 2021
    On 31/10/2021 01:23, John McCue wrote:

    Kenny McCormack wrote:

    Noob wrote:

    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    My first (and best) thought was to do it via grops. Seems tailor-made for >> this.

    I'd create a new group (Say, foo-bin-users) and add your user to that
    group. This makes it easy to add others in the future.

    That was what I thought too, then I realized may be better
    to not bother with getuid(2) getgid(2) and just do:

    # chgrp foo-bin
    # chmod 750 foo-bin

    Then it is not tied to a specific hard-coded ID/Group
    and no setgid needed

    Hello John,

    I'm not sure I understand the specifics of your suggestion.
    (And how it differs from Kenny's and my own second solution?)

    (In solution #1, I used getuid.
    In solution #2, I used "regular" Unix permissions.)

    In your proposed solution,
    What group does foo-bin belong to? (chgrp GROUP FILE)
    Also, you dropped the set-user-id bit, this cannot work.

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Noob on Sun Oct 31 10:50:10 2021
    Noob <root@127.0.0.1> writes:
    In your solution, how would your sudo suggestion work?
    You would add user12345 to the sudoers group?
    But then user12345 could do anything that root can.
    I want user12345 to be able to run foo-bin as root, nothing more.

    sudo can supposedly restrict privileged execution of certain commands to certain users. (I say “supposedly” due to its rather sad CVE record.)

    Do you see any security issue with my solution #1?
    I'll adopt solution #2 in production, but I wanted to hear people's opinion as to why solution #1 fails ;)

    It works in its environment, but it’s not robust against changes to that environment, e.g. if it gets moved to a different system, or the system
    gets reinstalled for some reason, or the rules change about which
    user(s) should be able to execute it. Whether relevant changes to its environment are likely is not something anyone else can predict for you.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John McCue@21:1/5 to Noob on Sun Oct 31 13:48:18 2021
    Noob <root@127.0.0.1> wrote:
    On 31/10/2021 01:23, John McCue wrote:

    Kenny McCormack wrote:

    Noob wrote:
    <snip>

    That was what I thought too, then I realized may be better
    to not bother with getuid(2) getgid(2) and just do:

    # chgrp foo-bin
    # chmod 750 foo-bin

    Then it is not tied to a specific hard-coded ID/Group
    and no setgid needed

    Hello John,

    I'm not sure I understand the specifics of your suggestion.
    (And how it differs from Kenny's and my own second solution?)

    (In solution #1, I used getuid.
    In solution #2, I used "regular" Unix permissions.)

    In your proposed solution,
    What group does foo-bin belong to? (chgrp GROUP FILE)
    Also, you dropped the set-user-id bit, this cannot work.

    foo-bin would be 750:
    -rwxr-x--- 1 root foo-bin .... foo-bin

    then only User IDs in group foo-bin would have execute
    access to it. You would need to create a group named
    foo-bin (or whatever you would like to use) and add users
    you want to execute binary foo-bin to that new group.

    You can even get fancier if you system supports ACLs.

    https://en.wikipedia.org/wiki/Access-control_list

    but the end result is you can avoid using a set[gu]id
    and hardcoding a check in the binary.


    Regards.

    --
    csh(1) - "An elegant shell, for a more... civilized age."
    - Paraphrasing Star Wars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Noob on Sun Oct 31 21:04:28 2021
    Noob <root@127.0.0.1> writes:
    I've written my first Linux set-user-id-root program (let's call it foo-bin)

    foo-bin is suid-root because:
    1) foo-bin is supposed to be run by an unprivileged user,
    2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

    [...]

    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    That's what I usually do as a decision re: who is or isn't allowed to
    run this falls into the realm of administrative policy which shouldn't
    be hardcoded (IMHO).

    Also, 4710 is sufficient: It's not necessary to read a file in order to
    execute it, ie, while the kernel obviously has to, processes running
    with the uid of a user supposed to be allowed to execute a file don't
    need to read its contents.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to Rainer Weikusat on Mon Nov 1 01:59:52 2021
    On 31/10/2021 22:04, Rainer Weikusat wrote:

    Noob writes:

    I've written my first Linux set-user-id-root program (let's call it foo-bin) >>
    foo-bin is suid-root because:
    1) foo-bin is supposed to be run by an unprivileged user,
    2) foo-bin makes privileged system calls (unshare, chroot, mount, setgroups)

    [...]

    There's a different approach that would also work:
    1) put foo-bin in user12345's group (chown root:user12345 foo-bin)
    2) allow group to run foo-bin, not others (chmod 4750 foo-bin)

    That's what I usually do as a decision re: who is or isn't allowed to
    run this falls into the realm of administrative policy which shouldn't
    be hardcoded (IMHO).

    You make a convincing argument.

    Also, 4710 is sufficient: It's not necessary to read a file in order to execute it, ie, while the kernel obviously has to, processes running
    with the uid of a user supposed to be allowed to execute a file don't
    need to read its contents.

    Your answer makes me wonder:
    How much/little additional security do I get from mode 4710 instead of 4750?
    In other words, what bad things can user12345 do if they can read the
    ELF executable file?
    Maybe disassemble the code? To prepare a ROP exploit in advance?

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Noob@21:1/5 to John McCue on Mon Nov 1 01:54:31 2021
    On 31/10/2021 14:48, John McCue wrote:

    Noob wrote:

    (In solution #1, I used getuid.
    In solution #2, I used "regular" Unix permissions.)

    In your proposed solution,
    What group does foo-bin belong to? (chgrp GROUP FILE)
    Also, you dropped the set-user-id bit, this cannot work.

    foo-bin would be 750:
    -rwxr-x--- 1 root foo-bin .... foo-bin

    then only User IDs in group foo-bin would have execute
    access to it. You would need to create a group named
    foo-bin (or whatever you would like to use) and add users
    you want to execute binary foo-bin to that new group.

    As far as I can tell, your suggestion is the same as Kenny's.
    He wrote: "I'd create a new group (say, foo-bin-users) and add
    your user to that group."

    It is also the same as my proposed solution #2 (I just used
    a different group name).

    Also, I can't strip the setuid bit off, otherwise foo-bin
    won't run with root privileges.


    but the end result is you can avoid using a set[gu]id
    and hardcoding a check in the binary.

    Right. That's what I did in my proposed solution #2.

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    Regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John McCue@21:1/5 to Noob on Mon Nov 1 02:02:54 2021
    Noob <root@127.0.0.1> wrote:

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    The main issue with having the check you propose hard-coded
    inside the program will only allow 1 specific user to
    execute.

    What happens if you want other people to run the program ?

    Also there is no guarantee user '12345' does not already
    exist on a different system.

    You may be forced to maintain separate binaries on each
    different system or maintain separate configuration file the
    program reads in to determine who can run it.

    To me, best to use security settings UN*X already provides
    for 'free' instead of designing your own.

    HTH
    John



    Regards.

    --
    csh(1) - "An elegant shell, for a more... civilized age."
    - Paraphrasing Star Wars

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to root@127.0.0.1 on Mon Nov 1 05:34:43 2021
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:
    ...
    As far as I can tell, your suggestion is the same as Kenny's.
    He wrote: "I'd create a new group (say, foo-bin-users) and add
    your user to that group."

    Right.

    It is also the same as my proposed solution #2 (I just used
    a different group name).

    IIRC, your original post suggested using your user's already existing
    group. This is somewhat less portable than creating a new group (speciic
    to this purpose).

    Also, I can't strip the setuid bit off, otherwise foo-bin
    won't run with root privileges.

    Right. I think that was just a routine "thinko" on Keith's part.

    but the end result is you can avoid using a set[gu]id
    and hardcoding a check in the binary.

    Right. That's what I did in my proposed solution #2.

    Right.

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not
    best practice - and not as "future-proof" as using a group would be.

    --
    The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
    to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

    H. L. Mencken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Kenny McCormack on Mon Nov 1 14:59:12 2021
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:

    [...]

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not
    best practice - and not as "future-proof" as using a group would be.

    It "will work" for as long as all systems the binary is copied to will
    always associate the intended user with the hard-coded UID. As there's
    nothing in the binary which screams "I have 66771 hard-coded as UID for
    user grmblfzz!", that's bound to break even on a single system as stuff
    like this tends to be forgotten over time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Noob on Mon Nov 1 15:07:34 2021
    Noob <root@127.0.0.1> writes:
    On 31/10/2021 22:04, Rainer Weikusat wrote:
    Noob writes:

    [...]

    Also, 4710 is sufficient: It's not necessary to read a file in order to
    execute it, ie, while the kernel obviously has to, processes running
    with the uid of a user supposed to be allowed to execute a file don't
    need to read its contents.

    Your answer makes me wonder:
    How much/little additional security do I get from mode 4710 instead of 4750? In other words, what bad things can user12345 do if they can read the
    ELF executable file?
    Maybe disassemble the code? To prepare a ROP exploit in advance?

    Some protection against someone analysing the binary in order to find a
    way to exploit it. That's presumably more than a bit theoretical, hence,
    this is something of a "ticking the box" exercise. OTOH, it can be done
    easily and there's usually nothing which can be gained by allowing read
    access.

    I usually do it because I expect to have to deal with the output of
    "pen testers" (aptly named as their work consists of testing that they
    can use a pen to write down a list of possibly existing vulnerabilities blindly) who will flag all unticked boxes they find somewhere as
    Unticked !!1 (OMG !!2).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to rweikusat@talktalk.net on Tue Nov 2 13:49:54 2021
    In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:

    [...]

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not
    best practice - and not as "future-proof" as using a group would be.

    It "will work" for as long as all systems the binary is copied to will
    always associate the intended user with the hard-coded UID. As there's >nothing in the binary which screams "I have 66771 hard-coded as UID for
    user grmblfzz!", that's bound to break even on a single system as stuff
    like this tends to be forgotten over time.

    IOW, you agree with me, 100%. Thanks.

    --
    A racist, a Nazi, and a Klansman walk into a bar...

    Bartender says, "What will it be, Mr. Trump?"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Kenny McCormack on Tue Nov 2 16:09:54 2021
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:

    [...]

    It's not yet obvious to me (at this point) why it's a terrible idea
    to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not >>> best practice - and not as "future-proof" as using a group would be.

    It "will work" for as long as all systems the binary is copied to will >>always associate the intended user with the hard-coded UID. As there's >>nothing in the binary which screams "I have 66771 hard-coded as UID for >>user grmblfzz!", that's bound to break even on a single system as stuff >>like this tends to be forgotten over time.

    IOW, you agree with me, 100%. Thanks.

    I don't. Hard-coding system configuration information will work for as
    long as the binary is regarded as configuration and the system
    configuration as binary, IOW, what's supposed to be changeable by users
    becomes cast in stone in this way while developers can "save some work"
    in exchange for that.

    I consider this a wrong design choice.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to rweikusat@talktalk.net on Tue Nov 2 17:17:28 2021
    In article <87h7cuo7xp.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote:

    [...]

    It's not yet obvious to me (at this point) why it's a terrible idea >>>>>to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not >>>> best practice - and not as "future-proof" as using a group would be.

    It "will work" for as long as all systems the binary is copied to will >>>always associate the intended user with the hard-coded UID. As there's >>>nothing in the binary which screams "I have 66771 hard-coded as UID for >>>user grmblfzz!", that's bound to break even on a single system as stuff >>>like this tends to be forgotten over time.

    IOW, you agree with me, 100%. Thanks.

    I don't. Hard-coding system configuration information will work for as
    long as the binary is regarded as configuration and the system
    configuration as binary, IOW, what's supposed to be changeable by users >becomes cast in stone in this way while developers can "save some work"
    in exchange for that.

    I consider this a wrong design choice.

    Right. We totally agree. Note: You may have to go back and read
    carefully, and note which parts were written by who and when and why. It
    make take some careful reading to get the point.

    Don't worry. I'll wait.

    --
    The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
    http://user.xmission.com/~gazelle/Sigs/Rorschach

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Kenny McCormack on Tue Nov 2 19:25:16 2021
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <87h7cuo7xp.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <871r3zexbz.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>>gazelle@shell.xmission.com (Kenny McCormack) writes:
    In article <slnds7$n5q$1@dont-email.me>, Noob <root@127.0.0.1> wrote: >>>>
    [...]

    It's not yet obvious to me (at this point) why it's a terrible idea >>>>>>to hard-code the check in the binary, though.

    There's nothing per se wrong with it - it will work - but it is just not >>>>> best practice - and not as "future-proof" as using a group would be.

    It "will work" for as long as all systems the binary is copied to will >>>>always associate the intended user with the hard-coded UID. As there's >>>>nothing in the binary which screams "I have 66771 hard-coded as UID for >>>>user grmblfzz!", that's bound to break even on a single system as stuff >>>>like this tends to be forgotten over time.

    IOW, you agree with me, 100%. Thanks.

    I don't. Hard-coding system configuration information will work for as
    long as the binary is regarded as configuration and the system >>configuration as binary, IOW, what's supposed to be changeable by users >>becomes cast in stone in this way while developers can "save some work"
    in exchange for that.

    I consider this a wrong design choice.

    Right. We totally agree. Note: You may have to go back and read
    carefully, and note which parts were written by who and when and why. It make take some careful reading to get the point.

    I don't agree with your "it will work, it's just not best practice and
    not as future proof as" judgement. It will only 'work' under very specific circumstances and at the expense of breaking other parts of the system.

    That's something people might (for more or less good reasons) not be
    worried about but this should at least be an informed choice.

    Figuratively spoken: Kicking the door to one's home in instead of
    opening it with a key will also 'work'. But afterwards, the door won't
    work anymore.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to rweikusat@talktalk.net on Tue Nov 2 20:22:02 2021
    In article <87czninyw3.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    ...
    I don't agree with your "it will work, it's just not best practice and
    not as future proof as" judgement. It will only 'work' under very specific >circumstances and at the expense of breaking other parts of the system.

    That's something people might (for more or less good reasons) not be
    worried about but this should at least be an informed choice.

    Figuratively spoken: Kicking the door to one's home in instead of
    opening it with a key will also 'work'. But afterwards, the door won't
    work anymore.

    Oh well. Back to reading comprehension school for you...

    I said "It will work (*), but it is not best practice (**)". What more can
    I say?

    (*) Which it will.
    (**) Which it (clearly) isn't.

    --
    "There are two things that are important in politics.
    The first is money and I can't remember what the second one is."
    - Mark Hanna -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Kenny McCormack on Tue Nov 2 21:28:11 2021
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    ...
    I don't agree with your "it will work, it's just not best practice and
    not as future proof as" judgement. It will only 'work' under very specific >>circumstances and at the expense of breaking other parts of the system.

    That's something people might (for more or less good reasons) not be >>worried about but this should at least be an informed choice.

    Figuratively spoken: Kicking the door to one's home in instead of
    opening it with a key will also 'work'. But afterwards, the door won't
    work anymore.

    Oh well. Back to reading comprehension school for you...

    I said "It will work (*), but it is not best practice (**)". What more can
    I say?

    (*) Which it will.
    (**) Which it (clearly) isn't.

    And I said, Mr InNeedOfReadingComprehension, "it really doesn't work"
    and providing a reason for that. People may disagree with this
    assessment, but that's my opinion.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to rweikusat@talktalk.net on Wed Nov 3 10:06:26 2021
    In article <878ry6nt78.fsf@doppelsaurus.mobileactivedefense.com>,
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    gazelle@shell.xmission.com (Kenny McCormack) writes:
    Rainer Weikusat <rweikusat@talktalk.net> wrote:
    ...
    I don't agree with your "it will work, it's just not best practice and >>>not as future proof as" judgement. It will only 'work' under very specific >>>circumstances and at the expense of breaking other parts of the system.

    That's something people might (for more or less good reasons) not be >>>worried about but this should at least be an informed choice.

    Figuratively spoken: Kicking the door to one's home in instead of
    opening it with a key will also 'work'. But afterwards, the door won't >>>work anymore.

    Oh well. Back to reading comprehension school for you...

    I said "It will work (*), but it is not best practice (**)". What more can >> I say?

    (*) Which it will.
    (**) Which it (clearly) isn't.

    And I said, Mr InNeedOfReadingComprehension, "it really doesn't work"
    and providing a reason for that. People may disagree with this
    assessment, but that's my opinion.


    Projection, much?

    --
    I voted for Trump because I thought he'd make pussy grabbing legal.
    I honestly don't see any other way America could be made great again.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)