Re: user perms
On 6/15/22 01:00, David Wright wrote:
And I'm going to snip down to what I'm replying to, I think.
I am not at all sure tbird will do as I ask though.
So my only instant question is when will the developers understand that
stuff that runs as a $USER, needs one of two changes, either a .conf file
someplace readable by the $USER that tells things like t-bird, running as
the user, can have write privs to /var/log, /or/ an entry in that *.conf so
logging can be done instead of just gobbling up the denial w/o bothering
to tell the user it can't open the log. Its trivial to fix logrotate
to service
the logs in /home/$USER/logs where there's no perms problem because
the $USER owns the whole path.
No idea what this is all about, sorry.
The above s/b one quote level but tbird won't lt me fix it. and
now my additional reply is munged, backspaces or Del's will not "take"
What the heck is this vertical bar it uses for a quote level, whats wrong
with > >> etc for quote indicators? There's a button containing an A
overlaid by a graphical double square as the last line above the window
that claims to "remove text styling" but it does nothing. Under options
->delivery format, plain text is checked, but obviously its still sending
and rendering what I see as HTML. That's not the end of the bug list
Same perms story for heyu and nut,
but some somebody, thinking security as opposed to usability, insists
on building /dev/ttyUSB*, with 0660 perms. Neither nut, nor heyu can
get past that to get their job done. And IF I reset those two devices
to 0777, it all works but a reboot screws it up again
I must have asked 15 or 20 times in the last decade, how to fix this in
permanently in /lib/udev, and have been ignored when I ask that for
several years. Usability, letting a computer actually DO its job simply
isn't on the menu. With a record like that, can you blame me for being
frustrated? Frustrated by asking for advice so I do do it right, and being
ignored.
The trouble with writing this is that people can look back.
There was a thread in May 2020 on this topic, where all your posts
have followups except for the two that sign out just like this one
does below; ie "Now I know how but my editing foo is burned out for
today", and "I'll see about it tomorrow, having used up my creative
juices on another project today".
In that thread, there is a working set of rules showing how udev
runs a script when a USB stick is inserted or removed, the scripts
themselves, and the data files that the scripts read¹. The scripts
have no problem performing mkdir and rmdir in the /media directory:
USB sticks aren't the issue here, serial adapter's are.
$ ls -ld /media
drwxr-xr-x 3 root root 4096 Jun 14 08:30 /media
$
[...]
You're a goddamned 20+ year Linux veteran. You should be able to
handle something as ridiculously simple as this.
Generally I can. but a reboot fixes things so I have to do it
all over again at every reboot, just because this list refuses
to answer a simple question about setting the perms on 2
devices that are identified as /dev/ttyUSB*.
This install feels good yet, but at 36 hours uptime, I've used
half the typical uptime I've managed in 30 previous installs.
I have had to replace some memory, but now memtest can't
be found, I guess because it is a 16 bit build, and can't be
changed. But it ran ON THIS 6 core i5, probably 8 or 9 times
pre bullseye.
So what replaces it? From the thread about its MIA status, I
am not the only one wanting it or a 64 bit substitute back
on the grub menu.
I have a $100 bill for the talented coder who brings that
or a new 64 bit from scratch version back.
Payable by whatever legal means puts the money in his or
her pocket to extend the height of their ladder up the side
of the hog.
As usual, we don't know what you actually did to handle it.
yes I did, but you snipped that part. How convenient...
Get a grip: your entire post was quoted in mine, apart from your signature.
So I write it again:
As soon as it rebooted from the install, and I had gained root,
I nano'd /etc/group and added me to group lp, so I could configure
my 2 printers.
I see; so messing about with /etc/group was "handling it". Well then,
I'll repeat myself too:
> > "adding myself to /etc/group in the appropriate places" sounds just
> > like the sort of thing that might have caused /etc/passwd to become
> > screwed up in installation #31.
The catted group listing today, from install #32, now has
me all over that file 12 times where the previous 31 installs only had
me in sudo.
Is that because I finally gave up and defined a root pw during the install?
In that event IMNSHO the installer is broken in 2 ways. In ways not
apparently
related to to the auto install of all the brltty and orca crap that
drives a
sighted person into screaming fits. It stalls the machine while it
trying to
speak every keypress, fails because it hasn't learned how to speak English
and can't be turned off w/o destroying the uptime.
I've met your blind person. He is running OpenSCAD, the gfx composer
from that synth. I'd have to assume it speaks a lot better german than
it does English. I have to admire his determination,
he has a quadruple share of it to run OpenSCAD blind.
If that's not changeable, then it should advertise the diff, but it
does not.
I have no idea what this is all about, sorry.
And I'll repeat: The first 25 installs were because the D-I,
if it sees a serial adapter, does not ask you if you want
the braille stuff, it installs it automatically, and
by the time I had killed the orca output, it was not rebootable
without a re-install. And when someone finally said why, and
that I had to unplug any serial adapters to stop that bs, it didn't
make a lot of sense to me. Serial adapters are used for a lot of
other stuff, not exclusively to drive /Dev/brltty and orca.
cm-11a's for heyu to control your household lights and
appliances with the x10 protocol are just one example.
UPS's, even tho they are usually seen thru a usb port,
were usually treated as a serial device, but udev now
recognizes them as a ups. It did not for wheezy. So that's
one bug fixed.
but haven't changed the perms of /dev/ttyUSB* yet.
Of course, the idea was that /you/ don't have to do that: udev should
do it when you boot up the machine or plug in the items. That's what
makes it permanent. And by reading their distinctive serial numbers,
FTDHG45D and FTOOS09N, it also prevents the names of the two devices
being swapped around by a race, or the order of insertion.
It does not!!!!!!!!!! That's what I'm screaming about.
It sets the perms so only root can use them. I just
plugged at least one of them in:
root@coyote:/lib/udev/rules.d# ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun 15 05:31 /dev/ttyUSB0
020660. The common user can't touch it. So what IS
the "approved fix" so the user CAN use it? A fix that
will actually survive a reboot. That's the question
asked that every reply so far has ignored.
.
I've noted that that does seem to be stable now, but why does
it have to be owned by root:root, and 0600 perms? I have rather
diligently searched thru /lib/udev/rules.d without finding where or
how the perms are applied. And questions asking about it are snipped
and never replied to. Why?????????
A rebuttal is already in your quoted material, above.
On the subject of /lib/udev/rules.d, I have no idea what's in there,
or what's meant to be in there, that would apply to your particular
devices: I don't know anything about them.
But you can write your own rules in /etc/udev/rules.d/, as I have
done, and tailor them to your specific requirements. Don't touch
the ones in /lib/udev/rules.d/, but use them as a pattern. (You
can also override them by using the same filename.)
$ grep '\<MODE\>' /lib/udev/rules.d/* | less
shows that dozens of them set permissions, and would show you
how it's done.
Only so
much time in one 24 hour day. Up since 4:40 my time, by 20:00 I'm burned
out for the day.
¹
https://lists.debian.org/debian-user/2020/05/msg00510.html
Is my answer as to how to fix this perms problem actually
contained in that post and I'm not reading between the lines
well enough to grok it? Could happen you know...
No it isn't. My example is for how you configure udev so that
it performs things for you, with the necessary privilege, the
idea (one of them) being that you don't have to chmod 777
every darn thing to make them work.
Unlike the email posts, the web version doesn't show that
"usgs1g" (the mount point) is the contents of an attached file
called "2017-0403" (the USB stick's UUID), and likewise "cdrom3"
in file "KZ3E2DH0440" (the portable DVD Writer's serial number).
today, usb-devices does not show the most valuable info, it does
not show the mount point
/My/ example is for usb-devices that are mass-storage (sticks,
cards and drives), and so it deals in mount points. Your devices
aren't.
Because at the moment, none of the serial adapters
were plugged in. They both are now. and despite
me, heyu, & nut
being added to the dialout group, neither utility can talk to
its hardware, no permission. So I'll remove the additions to /etc/group
and await advice.
/lib/udev/rules.d/ unsurprisingly contains examples of
almost every sort of device.
But not once does is specifically mention /dev/ttyUSB. Its a bit
hard to find the rule for a serial adapter when its not mention
any place it the whole directory tree.
Now, the weather has quieted, and I have a 1/4" square pcb to design
and make for
one of my cnc'd machines, on that same machine. I'm adding an air
pressure controller
to the mister nozzles air supply.
Can't help with that.
Got that done, the gage module reflow soldered to it, and
mounted to the base plate that fits in an extruded box
holding a development board for a high voltage op-amp
that I yet to populate with the 603 sized parts that will
bring it to life.
BTW your previous post was doublespaced, and this one had all the
blank lines taken out, making it difficult to see where replies
begin and end. I'm not sure why. (Anyway, I've inserted them again.)
Just one of the t-bird bugs, I see this sentence is in a larger type,
but I've no clue why. I haven't specifically changed it nor have I
used t-bird for a mailer for a decade, and in that decade it still
hasn't grown the ability to send good, word wrapped plain text,
or display it properly. If there is a special key combo that brings
up a menu to select that stuff, I've not found it yet. If I ask it to
rewrap, it will rewrap only the original content, but not my reply
additions. Just one of the reasons I say its buggier than roadkill
in august.
Cheers,
David.
.
Take care and stay well David, and thanks,
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Reply to: