At a previous job, I had to use newgrp quite frequently. There's a limit on the number of "active" groups you can be in at a time, typically 16. Groups were used for permissions for directories on network storage and our version control system at the time. As far as I'm aware, I was the only person at the company affected because I touched so many different repositories, I was a member of around 20 groups. I had to bounce between them using newgrp (albeit without passwords as in TFA).
I forget the exact reason for the limit of 16, but I think it was an NFS limit.
> There's a limit on the number of "active" groups you can be in at a time, typically 16. Groups were used for permissions for directories on network storage and our version control system at the time.
This is a limitation of NFS, or more specifically AUTH_SYS per RFC 5531 (§A):
A lot (most?) NFS appliances tend to have a setting where you can tell them to ignore the group list that comes in on the RPC call and just do a look-up on the UID themselves: this way they get the full list via LDAP/NIS/AD/whatever and then do permission checks from that.
My hack to get around this was to have the user an groupadmin but not necessarily a member of the group. Then that user could add and remove themselves from a group as required, keeping under the 16 limit.
The newgrp command also changes your primary group. This affects the gid on new files that get created (a field in the new file's inode).
Try these commands:
id
touch a
newgrp cdrom # or any group other than the first one
id # note that gid is now 'cdrom',
# and it's also first on the groups= list
touch b
ls -l a b # note different group ownership
exit # leave the extra shell that newgrp created
This can actually save steps if the gid of newly-created files matters because it can avoid an extra chgrp command (which saves typing and avoids a little I/O).
Good point. I hadn't thought about that. With careful use of umask, chgrp, and chmod (in that order and with proper error handling), you could protect yourself, but just setting it to the right value in the first place seems simpler.
If you're talking about command line programs (as opposed to fchown/fchmod on an open fd), there's still a race whereby an attacker in the shared group can make a link and get you to chgrp away one of your personal files.
Your comment reminded me of the classic Ken Thompson quote:
>Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."
There was definitely a mentality at this time that symbols should be short. Probably partly because of the low resolution terminals of the time, and especially teletypes but also maybe because of different practices and a different ecosystem. That's how we ended up with /usr instead of /user and /mnt instead of /mount.
One of the original limits was 6 significant initial characters for extern C identifiers - even in 1980s, this was still prevalent enough that ISO C90 codified it. The easiest way to conform is to ensure that you don't have any function names longer than that. I believe this is why there are so many names like "strcpy" and "tmpnam" in the C standard library. Later additions are often not quite so laconic - e.g. it's "tmpfile", not "tmpfil".
And then many Unix shell utilities are themselves counterparts of the corresponding C APIs - e.g. "chown". It stands to reason that they'd have identical names; but in doing so, they would also set a precedent for that kind of shortening in general. So if you already have "chown", then why not "chgrp"? And if you have "chgrp", then you'd probably want "newgrp" rather than "newgroup".
Home directories were originally stored in /usr, as are another user programs
“ In particular, in our own version of the system, there is a directory "/usr" which contains all user's directories, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk. “
Not sure if it was actually relevant at the time of Unix v6, but Brian Kernighan writes in his memoir that "Arguably, one reason why many commands on Unix are short is that it took considerable physical force to type on a Model 33, and printing was slow. [10 characters/second]"
I worked with some sales people in a pre-sales role. This came up during prep for a presentation. A couple of us were on the command line on the projector. There was the usual chatter about getting the magic incantations right, and how come nothing is fully spelled out, etc...
Two of the women on the team brought up middle school notes and how they would often leave a lot out.
When people are familiar, there is a shared mini culture in play. Slang, common expression.
They would use first letters only, with the odd fully spelled out words here and there. Sort of a game, how well do you know your friends?
"Haven't you ever done that?"
"Of course not."
"Yeah, boys."
"It's fun"
And of course we started to play this silly game at work.
NH!
BRT
TY
YAW
YATB!
Soon, paragraphs became sentences.
Turns out a whole lot can be said this way and how well it is received is a direct function of how closely anyone reading are to the people exchanging the messages.
And it worked. Anyone playing got a lot closer to others also playing.
A fun friendship lark.
All that *nix stuff works the same way. Culture, familiarity...
Never thought about it that way myself, until that workplace word play happened.
The same sort of mapping to meaning seems to happen with shortened commands. It is all just lean in a way that means less work for basically the same outcome.
I find the move to make one space after a period equally funny, BTW.
Every time I abbreviate something on mobile, I see the next character after a space go to capitalized mode and wonder how anyone expected the parser to differentiate that from end of sentence.
I remember years ago the behavior of groups in Solaris was quite different than in Linux or FreeBSD. Some standard functionality required running newgrp in order to be able to execute a file based on fs permissions. It was very annoying.
This was 20ish years ago, so I have no idea what the behavior of now.
Fun anecdote about Unix groups: when I worked at Netscape, managers were shocked to discover that I was in both the frontend and backend groups, against the policy of allowing one person to take over the web site. (I worked on both sides, so had been granted access to do my work.)
But it gets even better ... I also had admin access to many databases. :)
I forget the exact reason for the limit of 16, but I think it was an NFS limit.