RFE: scp and ssh should have an option to set the group-id at login time. On Unix/Linux one user can be part of multiple groups (like "% /usr/bin/id uid=2306(gisburn) gid=2306(gisburn) groups=10(staff),8000(xprint)") - it would be nice if there is an option which can be given together with "-l" (like "-G") to select the group-id (either via "name" or "group number") at login time. A failure to select the requested group should be treated as login failure.
sshd already sets up users with supplimental groups correctly. Why select one when you are already a member of all?
Damien Miller wrote: > sshd already sets up users with supplimental groups correctly. Why select one > when you are already a member of all? I want to be able to set the "current group" at login time. 1. Right now all files created by "scp" can only have the GID of the primary group and I have to "ssh" into the machine a 2nd time to run "chmod" on all new files. 2. I can't run scripts via "ssh" in any other group. In theory there is "newgrp" but that ONLY works in interactive mode since a new shell is spawned.
I really don't see a need for this. ssh -t site script will force a TTY so newgrp will work. sftp supports 'chgrp' for scripting. Plus I'm not sure we could enforce such behavior accross all the different security methods.
Ben Lindstrom wrote: > I really don't see a need for this. > ssh -t site script will force a TTY so newgrp will work. "newgrp" doesn't work even for "rsh" - and definately not for "ssh". "newgrp" doesn't allow to pass any arguments which will be executed. "newgrp" just starts a new shell and then does nothing until the EOF comes in. This is one of the oldest defects in Unix currently not being fixed (finally, the next version of the Single Unix Spec should fix that. Just took twenty years... ;-/ ... I hope OpenSSH will be slighly faster... :-))) ). > sftp supports 'chgrp' for scripting. Can you explain how I can use that from the ssh client side ? > Plus I'm not sure we could enforce such behavior accross all the different > security methods Uhm... login and then change the "egid" before invoking the command to execute ?
sftp comment was refering to REPLACING your scp usage. As for the rest of it.. <shrug> write your own verison of newgrp. I still don't believe OpenSSH has any business doing this type of tom foolery. Besides, even this feature was implemented in 2.9 it would FAIL to work with 2.8 and below and SSH Corp. So why bother implementing it? We will get more complaints then it is worth. - Ben
I don't think this feature is warranted. It probably would require a protocol extension to work correctly, would add further complexity and bloat to the client and server and can be worked around in other ways. Why not make a little "newgrp" replacement that does what you want and stick in in your shell initialisation?
Ben Lindstrom wrote: > As for the rest of it.. <shrug> write your own verison of newgrp. Uhm... I hope this was thought as a joke, right ? :) > I still > don't believe OpenSSH has any > business doing this type of tom foolery. This is NOT foolery unless you think that the whole group-id system in Unix/Linux is foolery, too. Unfortunately this was weakly (like the problem that "newgrp" isn't usefull for non-interactive usage) implemented in the past. But now people are working hard on it to get all Unix versions fixed. And Linux. And FreeBSD; OpenBSD and even MacOSX. And this bug is part of this effort. > Besides, even this feature was > implemented in 2.9 it would > FAIL to work with 2.8 and below and SSH Corp. If OpenSSH implements it I'll get SSH.com to implement it, too. > So why bother implementing it? See comments above. > We will get more complaints then it is worth. Who should complain ? The if both SSH.com and OpenSSH implement it others will likely implement it, too. It will take some time, but that's the way new features always go.
On 2004-03-31 10:41, Roland Mainz wrote: > "newgrp" just starts a new shell and then does nothing > until the EOF comes in. Exactly. Try this and you will see how easy it is to script: ssh -t host 'id; newgrp somegroup <<EOF id EOF ' The shell spawned by newgrp works just like any other program that accepts commands on standard input. Or am i missing something?
Damien Miller wrote: > I don't think this feature is warranted. Really ? See my previous comments. At some point all Unix tools should be fixed to allow proper usage of group mechanism. If OpenSSH would be skipped then this would be really a big loss... ;-( > It probably would require a protocol extension to work correctly, would add > further complexity and bloat to the client and server and can be worked around > in other ways. I disagree that this would be "bloat". You would only implement support for an existing Unix feature which is now going to be used more extensively. > Why not make a little "newgrp" replacement that does what you want and stick > in in your shell initialisation? Because there is no proper way to make such a "newgrp" replacement without huge pain. Such a wrapper MAY work in small lab environments but I doubt that a portable solution can easily be written.
Jim Knoble wrote: > Exactly. Try this and you will see how easy it is to script: > > ssh -t host 'id; newgrp somegroup <<EOF > id > EOF This solution is not portable.
On 2004-03-31 11:25, Roland Mainz wrote: > This solution is not portable. Please explain or point to pre-existing explanation.
> If OpenSSH implements it I'll get SSH.com to implement it, too. I don't think you understand: there is an IETF working group that standardises the SSH prototcol. OpenSSH implements these standards. Sometimes we might go outside this process for things that we feel are interesting or important, but this isn't one of them. > Because there is no proper way to make such a "newgrp" replacement > without huge pain. I don't believe you.
On 2004-03-31 07:50, Roland Mainz wrote: > 1. Right now all files created by "scp" can only have > the GID of the primary group and I have to "ssh" > into the machine a 2nd time to run "chmod" on all > new files. Depends. On filesystems with BSD behavior, new files (and directories) inherit the group of the enclosing directory. On filesystems with SysV behavior, setting the setgid bit (02000) on the enclosing directory causes created files and directories to inherit the group from the directory. Created directories also inherit the setgid bit. Generally, setting the setgid bit on every directory where the group should be preserved does what you need without "fixing" anything. What am i missing?
>> Why not make a little "newgrp" replacement that does what you want and stick >> in in your shell initialisation? > >Because there is no proper way to make such a "newgrp" replacement without huge >pain. Such a wrapper MAY work in small lab environments but I doubt that a >portable solution can easily be written. So if there is "no proper way" to do it outside of OpenSSH... Yet you think that there is a proper way to do it within OpenSSH. You got to be joking. Give me a break. If you want this... Implement it and use it yourself. Otherwise write a SSH draft to support this and get the IETF to approve it. I think we've all wasted enough time on this. - Ben
Jim Knoble wrote: > > This solution is not portable. > > Please explain or point to pre-existing explanation. The example assumes that "newgrp" accepts commands from stdin. This works for ksh88 (on Solaris, but Solaris's version of /usr/bin/ksh is heaviliy modified), ksh93 and bash2 but not for all other Unix shells. The OpenGroup manual page for "newgrp" lists "Not used" for "stdin", older docs say "behaviour undefined". That's why I say it's "not portable" - you're relying on undefined behaviour (the implementation of "newgrp" differs heavily between shells and Unix implementations anyway, just take a look at the rants in OpenGroups manual page, sections "APPLICATION USAGE" and "RATIONALE"... ;-( ).
Ben Lindstrom wrote: > >> Why not make a little "newgrp" replacement that does what you want and > >> stick > >> in in your shell initialisation? > > > > Because there is no proper way to make such a "newgrp" replacement without > >huge > >pain. Such a wrapper MAY work in small lab environments but I doubt that a > >portable solution can easily be written. > > So if there is "no proper way" to do it outside of OpenSSH... Yet you think > that there is a proper way to do it within OpenSSH. You got to be joking. > Give me a break. I said "no proper way ... without huge pain", not "no proper way". Yes, it is possible to do it but it isn't an easy task to do it. > If you want this... Implement it and use it yourself. Otherwise write a SSH > draft to support this and > get the IETF to approve it. I think we've all wasted enough time on this. I have to report the feedback from this list back to the task force first. And yes, it seems we have to go to the IETF directly (but that wouldn't be my job then...).
Mass change of RESOLVED bugs to CLOSED