#12373: Can't "su" to non-superuser : Permission denied
-------------------------+----------------------------
Reporter: ttcoder | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: R1/beta1
Component: - General | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------+----------------------------
Comment (by ttcoder):
IIUC the umask that's relevant is the one on the build-bot that created
the Haiku image used by me and Dane ? That's probably what you referred to
bonefish, just re-wording to be sure we are apples-to-apples.
Anyway I can make preparations to put my package "hack" in production, in
case there are obstacles to solving this ticket.. The directories are easy
to override without side effects, but overriding runtime_loader means it's
"cast in stone" and our stations will miss potential updates to it though,
so if there could be an interim fix (waiting for the big all-encompassing
fix) addressing just that one, that'd be great :-).
======
Regarding packagefs build, I retrieve it from
`/Haiku3/_develop_hrev/haiku/generated/objects/haiku/x86_gcc2/debug_1/add-
ons/kernel/file_systems/packagefs`
======
Dependancy wise, confirming, I need all 3 elements here. Each missing one
triggers an error:
- missing access to lib/ : `runtime_loader: Cannot open file
libreadline.so.6: No such file or directory`
- missing access to bin/: `Permission denied`
- missing access to runtime_loader: `Killed (by death)`
Only if my hack package does contain all three, I can su to tt_sguest
====
My 2 cents on rwx policy:
The process of building Haiku should be self-contained, directed by
Jamfiles directives, rather than environmental values like umask that are
all over the place
That should be configurable (by e.g. changing the value of $(EXEMODE) &
friends in UserBuildConfig) for those that need custom tailored builds,
but other than that, people should have an assurance that if they use an
out-of-the-box git clone of the Haiku repository, they can build a
reproducible, apples-to-apples Haiku image on any computer they have,
without mysteries.
If you look at OpenSSH for example, it's software that has a very precise
idea of what each file's permission should be: the private RSA keys ''must
not'' be group-readable and world-readable, regardless of the umask. They
likely have parts of their makefiles or build scripts that hardcode access
to certain files in their "packages", simply because in some cases those
permissions serve a different purpose than umask (which serves a purpose
for day-to-day tasks, creating new files, not building packages or
operating systems). Other examples include executables that are "special",
like `su`, with the 's' bit to "inherit-root-privileges" (or conversely,
"do *not* inherit privileges"). If their makefiles/jamfiles relied on the
umask to get the correct right that would be a security risk. Rights are
(rightly) hardcoded for these. Deviations from these hard-codings should
be like changing the source code in .cpp files : something to do for
tinkerers and tweakers, not left to such general states as the general
umask IMHO. Might be missing something though, as my perspective is
colored by my being an app developer, not an OS developer..
--
Ticket URL: <https://dev.haiku-os.org/ticket/12373#comment:12>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
