I will not buy this record, it is scratched

Mihai Moldovan <[email protected]> Sat, 25 Nov 2017 20:37:03 +0100
Newsgroups	gmane.comp.tools.sudo.user
Message-ID	<[email protected]>
Hi

Let me start off with a few quotes:

sudo(8):
"-P, --preserve-groups
  Preserve the invoking user's group vector unaltered.  [**]By default, the
sudoers policy will initialize the group vector to the list of groups the target
user is a member of.[**]  The real and effective group IDs, however, are still
set to match the target user."

"COMMAND EXECUTION
When sudo executes a command, the security policy specifies the execution
environment for the command.  Typically, the real and effective user and group
and IDs are set to match those of the target user, as specified in the password
database, [**]and the group vector is initialized based on the group database
(unless the -P option was specified)[**]."


sudoers(5):
"preserve_groups   [**]By default, sudo will initialize the group vector to the
list of groups the target user is in.[**]  When preserve_groups is set, the
user's existing group vector is left unaltered.  The real and effective group
IDs, however, are still set to match the target user.  [**]This flag is off by
default[**]."


(Highlights added for the important parts.)

All this might be true in "the general case"™, but in one specific case, it
doesn't seem to hold: namely when executing a command as the same user.

My configuration defines this line, which should allow a user to execute any
command without asking for a password as long as the target user is the user itself:

x2go-jenkins ALL=() NOPASSWD:ALL


After executing sudo -i -u x2go-jenkins (as x2go-jenkins), I will expect the
groups vector to be re-initialized, as if the user went through a full login cycle.

This is not the case.


By contrast, hacking the PAM configuration so that the user can execute su in a
passwordless fashion as long as the target user is the user itself (in that
case, for instance running su - x2go-jenkins) actually reinitializes the groups
vector and goes through a full login cycle.


Now, people might wonder why one might need that in the first place. I am using
a schroot-managed chroot to build software and entering the chroot as the
unprivileged user x2go-jenkins. While that's working fine in general, the groups
applied are only those defined in the outer system, any groups setup in the
inner system are not automatically applied, since entering the chroot does not
go through a "full login cycle". I have been searching for a way to simulate
this full login cycle and started off with sudo - but it sadly doesn't seem to
work as advertised.

su does, but there is no way to disable it looking for a TTY, which is
problematic in case it's spawned from an interactive script called by Jenkins
(since Jenkins seems to output data as soon as a TTY is spawned - and while
that's not true for the ssh command at first, its slave program will open a TTY
and expect the master output - which fails if a TTY is spawned beforehand the
input consumed by some other program.)

Contrary, the need for a TTY can be disabled in sudo, which is great... if it
actually did what I'd like to have.


Is this a bug or intended feature?



Mihai

____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users
signature.asc (application/pgp-signature, 898 B)