Zap

Sat, 26 Jan 2019 16:49:36 -0400

This is now in red, zap, and osada and will show up in Hubzilla whenever it gets merged.
[master b9cef2f] command line tool for managing site admins

I'm very dis-heartened that several of the recent support issues on Hubzilla are people demanding the right to have a less secure system because security is getting in the way of something. Hence it must be dispensed with. Because those mean Hubzilla folks have archaic ideas and who needs security?

Sigh... I'm tired of this fight. I seem to recall going through it with my daughter. Every generation has to relearn the same gosh-darn things and make all the same mistakes because they refuse to listen to those who already made those mistakes and learned from them. I suppose we just have to let them find out all these things the hard way.

It's just such a waste of human effort.

show all 27 comments

Mario Vavti

Sat, 26 Jan 2019 16:55:47 -0400

🔁 Repeated @{}'s http://activitystrea.ms/schema/1.0/comment

Mike Macgirvin ⚡

Sat, 26 Jan 2019 17:10:06 -0400

Incidentally, there's existing code to prevent removing the account of the primary site admin if there is only one. I think this new tool will probably let you get around that; and will also let you remove all admins from your site without complaint. You can even create bash scripts to randomly designate different people as admin for a day. I suppose on the bright side it's all under your control and those mean Hubzilla devs won't try and stop you.

phani (Hubzilla)

Sat, 26 Jan 2019 17:54:04 -0400

i'm probably a bit dense today, but why does having another admin on a busy hub make a system less secure? i assume that the owner & original admin would have some common sense and not give 'admin' to any new user they don't know anything about...

h.ear.t

Sat, 26 Jan 2019 19:26:52 -0400

Having more admins makes the hub more vulnerable. If I need to get into the admin account to enable my own account as admin it's another risc.
I believe this is what he may be thinking about.

phani (Hubzilla)

Sat, 26 Jan 2019 19:32:25 -0400

Having more admins makes the hub more vulnerable.

only if you can't trust them. for me on my one-man-hub that's all theoretical, but when i think of a bigger one with hundreds of users, having another admin or perhaps even two, it might be easier to keep things in check, see what's happening with spam accounts, trolling, and such.

phani (Hubzilla)

Sat, 26 Jan 2019 19:41:48 -0400

on second thought, if creating another 'admin' by changing the DB directly is too much for the original one, it's not someone who really knows what they are doing, and perhaps shouldn't be able to take that decision. for me it makes no difference in the end: change the DB, use a CLI script, or some GUI option with scary warnings.

i just don't see why having another admin would make things more insecure generally.

Waitman Gobble

Sun, 27 Jan 2019 00:23:04 -0400

Thanks for the heads up. A thing i'm working on i thought admin was like the highlander. I will have to see how multiple heads fits into the picture

Giac El Vecio

Sun, 27 Jan 2019 00:42:17 -0400

I have been co-admin since the beginning, with only a few months break, indeed, I was already at friendica times.
I've never had problems with the main admin, but only with 'poorly regulated users' ;) .

Giac El Vecio

Sun, 27 Jan 2019 00:56:01 -0400

Houston, we have a problem.

https://zap.dog/display/b64.aHR0cHM6Ly96YXAuZG9nL2l0ZW0vMzQ5ZjM4ODgtYzk5NC00ZjVjLTk5YmUtYTNjNjdhNmRhNWNk

Giac El Vecio

Sun, 27 Jan 2019 00:58:38 -0400

a mix of public post/comments with private /post/comments...

boet

Sun, 27 Jan 2019 02:36:32 -0400

What's the purpose of having more than one admin account, if you can just share the one account you create at setting up your hub? I mean, Hubzilla is channel based, after all. So if you want to have multiple admins, you just create your hub with an admin channel and put all your content in another - separate -channel.

So you you wouldn't want to give a second person admin credentials, but share the log-in with another person. I don't see the reason why you'd want to have two accounts with admin rights in the first place - other than the convenience, that you don't have to log-out / log-in into that account for when you'd have to work as an admin.

Anyway, changing the database values to separate the admin role from your "private" channel, that's a one-time job and should be easy enough for a hub-owner.

Mario Vavti

Sun, 27 Jan 2019 03:00:29 -0400

a mix of public post/comments with private /post/comments...

This might be because zap.dog is not on the latest zap code.

You do not see this issue at the oruginal post...

phani (Hubzilla)

Sun, 27 Jan 2019 03:08:54 -0400

yes, is easy enough for a hub owner who knows what s/he is doing. with things like scriptaculous (or what's-it-called) that isn't always the case.

in my mind even admin tasks are personal. if i tell somebody to do or not do something i would do that as 'admin,' but that isn't only the role, it's also the person behind it. and with a big & busy hub it could be useful to have more than one person looking after it.

for me there are times when i can spend a lot of time with things like hubzilla, while at others i'm hardly able to log in. if i wanted to maintain a big hub it would be good to have somebody else looking after it when i couldn't.

i've seen it with Hz as well as D* that sometimes users have no idea who their hub- or podmin is. i don't like that. apart from the role, 'admin' is also a person. and if there are two or three different ones, that should be clear: who did or said what, so it can be discussed if necessary.

but in the end this is a non-issue since the option exists already. i was just interested to understand why mike and others consider it insecure to have > 1 admin.

Haakon Meland Eriksen (Zap Dog)

Sun, 27 Jan 2019 05:10:16 -0400

What is this about, root vs sudo role?

Mike Macgirvin ⚡

Sun, 27 Jan 2019 06:16:25 -0400

I don't care if you have 150 admins. What I've always pushed back on was having a webpage where admin rights could be handed out. This was an issue in Drupal for years. All it took was one plugin written by somebody with no security knowledge and anybody on the site could post a link to a forum and if the site admin tried to visit the link it granted admin rights to the bad guy and redirected somewhere else and the original site admin was none the wiser.

There are two ways of fixing this problem. You can verify your code against every poorly written plugin - including those that haven't been written yet; or you can make such sensitive operations such as handing out admin rights require DB fiddling at the site level. That's what we've done for years. We never stopped anybody from handing out admin rights to anybody they wanted, we just made sure that such acts were intentional and couldn't be accessed via a webpage.

This new script is blocked from direct access from the web in Apache. I haven't verified this under nginx or lightttpd any other homebrew webserver. I use Apache. I'd prefer the script didn't exist. If you use something else I guess we'll find out how good an admin you really are because if you aren't careful with your config files or don't have a web security background, I guess you're stuffed.

Mike Macgirvin ⚡

Sun, 27 Jan 2019 06:32:11 -0400

The weirdness is due to an interesting zot/zot6 compatibility issue.

Tanja ⚡

Sun, 27 Jan 2019 06:46:05 -0400 last edited: Sun, 27 Jan 2019 07:04:36 -0400

I saw the discussion about this in this post to the Hubzilla Support Forum. Initially, I agreed with Harald Eilertsen that an option in the Admin panel would be nice, but M. Dent explained why that would not be the greatest of ideas. I'm not an IT expert, so sometimes I don't always follow all ideas to their logical conclusions - sometimes it takes somebody who knows their to material explains things to me. I immediately thought, ok, I hadn't thought about this, but now that the reasoning is explained to me, I have to agree.

I would say that a CLI option is a compromise between convenience and security, but I'm wondering if it's worth it.

I'm aware that there are plenty of people who would choose convenience over security (I know enough of them personally), but is it really necessary to always give them what they want and compromise everybody else's security?

I am, however, aware that you might be in a difficult situation. I don't know anything about what's going on "behind the scenes" of Zot development, so if you feel you are fighting an uphill battle and getting tired of it, I can understand that, too.

Giac El Vecio

Sun, 27 Jan 2019 11:04:00 -0400

The weirdness is due to an interesting zot/zot6 compatibility issue.

really interesting:
in practice a private reshare of a public post has been glued to the original post , with private comments as well.

Giac El Vecio

Sun, 27 Jan 2019 11:09:48 -0400

in a general way (and not specifically zot - zot6) one could argue whether it is right/convenient to give a people the possibility of transforming a public post into a private reshare, perhaps it would be better not to allow it, and just allow public resharing (talking about pure resharing obviously and not a copy/paste)

phani (Hubzilla)

Sun, 27 Jan 2019 12:42:19 -0400

i just saw that in Hz dev. there is a new file: util/admins, which does exactly that: list, add, or remove hub admins. strange that this went thru without any further discussion, at least not visible...

Mario Vavti

Sun, 27 Jan 2019 13:00:35 -0400

I have just merged this into development branch during my (almost daily) hubzilla janitor task.
If it is not desired by the community we can still remove it... I have no issue with that...

Anyway, i do not see a big issue with the command line tool because it is (hopefully) only the "real" site admin with ssh access which has access to it and can execute it...

Also i think @Mike Macgirvin ⚡'s post is more about the general tendency than this particular feature.

phani (Hubzilla)

Sun, 27 Jan 2019 13:47:06 -0400

thank you, that explains it well. from earlier comments it seems that there are different positions in the community, and in the end all will accept what the powers that be decide, without too much grumbling. CLI tool seems like a good compromise between point-and-click and no change at all.

that general tendency you mention seems unavoidable if the aim is to bring Hz to the masses, so to say.

Mike Macgirvin ⚡

Sun, 27 Jan 2019 18:59:47 -0400

Cross-platform (zot <-> zot6) reshares should work a bit better now. There may still be some problems with cross-platform reshares where the reshare audience is private. I'll get to that one next.

phani (Hubzilla)

Sun, 27 Jan 2019 19:08:07 -0400

very good! these are thoughts i'm struggling with myself and haven't reached a conclusion yet. i really like the idea of 'packaging' Hz into an end-user product for a specific purpose -- but not to limit Hz itself to such. i also like the idea of small(ish) groups of users getting together around one or a few 'geeks' who manage the hub/server.

Marek Ľach

Tue, 29 Jan 2019 18:45:40 -0400

@Mike Macgirvin ⚡ Ideally usability and security kind of go as close together as possible, but as long as there is decent usability, it's probably more desirable I think to have superior security. Security gives your platforms a certain air of 'sophistication', or should I mean 'geekiness' that makes the software you write cool to use by those who are open minded and in the know about your security philosophy, I think.

Your endeavours are always exciting to watch and I wish you only the absolute best going forward.

Waitman Gobble

Wed, 30 Jan 2019 20:20:44 -0400

it was syncing up automagically, but maybe the branches changed, i might need to take a look that the updater

Waitman Gobble

Wed, 30 Jan 2019 20:36:53 -0400

Ok I think the sync is fixed again.. sorry people. it's counting the number of branches that return '[up to date]' - there were two branches a while ago, but now there are four.


# ./scan.sh 
From https://framagit.org/macgirvin/osada
 = [up to date]          dev        -> origin/dev
 = [up to date]          2.0RC      -> origin/2.0RC
 = [up to date]          flatten    -> origin/flatten
 = [up to date]          master     -> origin/master