151–160 of 175 posts
can someone post the following to a channel and delete everybody's home directory that reads it with usuc? : rm -rf ~/ [edit] They cannot. On careful rereading usuc passes the data through the pipe when writing a message, not reading it. So the channel is just full of raw terminal escape codes, if I understand correctly.
Earlier quoted context omitted.
What would you change about it ? I'd be happy to learn how to write better code.
OK, for starter the while loop. Main rule of writing shell scripts is, Use The Shell, Luke. Don't start external programs, if your shell (which is already running) can do it. "while /usr/bin/true" is nonsense, every time an external program gets executed for nothing. There are plenty of bash (since this shell is used in the example) internals, which evaluate to true, like ":", "test 1", "(( 1 ))", maybe others too. S…
Using builtins may be a security risk as they can be overloaded (hence the use of full paths everywhere).
I did not know about bash's extension of printf to print a date. I need to use the builtin to use it though. But I've received good advice elsewhere on how to do that securely, so I'll do it and do a write-up because it's not information that's easy to come by.
Your advice is very helpful, thank you.
Earlier quoted context omitted.
find . -type f -depth 1 -print0 | tr -d -c '\000' | wc -c GNU find has a -printf which would probably avoid the need to use tr. Personally, two hardlinks to the same underlying storage counts as two files to me, but I understand why you might disagree. I'd bet there's something out there that could give you only the count of unique storage areas, but I don't know how that interacts with deduplicating filesystems.
Nice! This wins :) I had to modify it a bit to get it to work cross-platform, but the approach does appear to be sound: find . -maxdepth 1 -type f -print0 | tr -d -c '\000' | wc -c I had originally written "Hint: it probably isn't what you think it is, if it's even possible", but after testing for a bit, I updated my comment in what was apparently a fit of hubris to say you couldn't.
Earlier quoted context omitted.
In what way is its functionality "nearly the same as Slack"? Or are people these days just using Slack as a generic term for "channel-based chat" without acknowledging the long history of chat apps? (In which case I would argue it is much closer to the functionality of IRC, if still significantly short of it).
I agree that Slack is much more featureful, but I fail to see what critical piece of IRC functionality is missing ? If anything, you don't need a bouncer for chat history with suc, so it's more featureful than IRC. With that said, I seldom used IRC so this is a genuine question for people who used it and miss some features.
Chapter 8 of The Linux Programming Interface mentions that applications running on Linux have basically 2 options for authentication: * Roll it themselves, maintain the database and all that jazz * Delegate it to the (very robust, very mature) Linux user authentication stuff Ever since reading that I've found myself wondering why more apps don't simply use SSH keypairs for authentication, given that they're already s…
If we really wanted MFA, we could roll a PAM module, and whatever pushes SSH authorized keys could also push MFA seeds. But IMO this would protect against very unusual attacks and annoy ssh agents users everywhere.
Most current distros prevent you from making setuid bash scripts, on security grounds. But you can get most of the same effect with a specific sudoers entry.
Until I found the wrapper file in the GitLab repo, I was holding out hope as I read through that there was some way.
Unfortunately I don't see any real way to avoid suid here, otherwise neat experiment. Posix ACLs might help, but the crucial part is prefixing the username to the message which requires privilege Lots of unix facilities are criminally underutilized in modern systems
I don't know how much effort is meant to be put into securing this from impersonation, but info can be pulled out of /proc/ if the permissions are set up right.
Earlier quoted context omitted.
This is a very astute way to look at it. I'd say then that the value of Slack is to be user friendly, which suc definitely is not for muggles. But then more difficult questions arise: - Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ? - Same question, but taking into account that Slack captures your data and won't give it back to you ? How…
> But then more difficult questions arise: - Is the price of slack worth it, when the alternative is having more educated users that can do very basic command line calls ? I'm not sure that it would be difficult to wrap that up in a web interface running on a single server that does nothing but execute those command-line calls - auth, data and everything but session would be managed by the web server. You could perha…