0

followup question to https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts . there is a very good answer by Gilles. alas, I do not understand it. nothing described there seems intrinsically different between executables and interpretables.

  • scripts had a race file-replacement condition, but Unix locking is not necessary to fix this. any C executable is first read and then executed. this could be done as easily with the interpretable code as with executable code. most (shell) scripts are not longer than most C executables, either, so both can be loaded first. the fact that earlier implementations first read one line, then closed the file, then reopened it (and thus suffered this race condition), is not intrinsic. it just happened to be ancient implementation. is this not easily universally fixable in all unix implementations by reading the whole interpretable script file?

  • the run-time necessary to accomplish a specific function is vulnerable, but this applies to both C code and the interpreter. do, say, shell or python scripts add/have vulnerable runtimes?

  • any (C) executable can call other shell programs the same way that an interpreted language can. programs passing to one another was originally claimed to be the Unix way, so we should do this often.

all of this is more or less stated in Gilles' answer, perhaps except the explicit "read all first, execute second". instead, it describes /dev/fd/ equivalent implementations.

so I am still missing it. what is intrinsically different? (the only security feature I can think of is that by banning suid scripts, we have made it more difficult for noobs to write any setuid scripts.)

was there a committee that made and explained their decision for, say, ubuntu, where I can read the motivation?

/iaw

2 Answers 2

0

Sure, it's possible to change the implementation to be secure, but in practice, it requires the cooperation of every Unix vendor, and a lot of user re-education. If you're able to coordinate such an effort, more power to you. :) The alternative (e.g., sticking with setuid wrapper programs) may be inconvenient, but it's not intolerable.

Put another way, there are good reasons we still can't properly spell create. The amount of effort required to fix this is just not judged to be commensurate to the benefit.

2
  • 1
    thx, but this also escapes me (pun?). any unix distribution can do this. it does not have to be coordinated. creat presumably has to be the same as it was for POSIX ?!
    – ivo Welch
    Commented Sep 13, 2014 at 22:42
  • It does have to be coordinated. No one wants to write a script that is designed to be run setuid, and then find that a bunch of users can't successfully run it because their particular OS hasn't added support.
    – jjlin
    Commented Sep 13, 2014 at 23:05
0

It's much easier to modify a shell script than it is to modify a binary file. No special tools are needed other than an editor , and write access to the file. Even sed works, but that is still a stream editor.

It does make sense from a security perspective, though. You can run a script through sudo, or su to root. You can always run an suid program within a script....

1
  • I think "security by obscurity" ["it's much easier"] is no part of it -- I'm not aware of any Unix solutions that used executor-writable SUID files for gating privileges. Commented Sep 27, 2022 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .