Re: user perms

[gene heskett]

On 12/8/23 12:11, David Wright wrote:

On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:

On 6/13/22 14:36, Greg Wooledge wrote:

On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
I appear as user 1000 seem to be stuck behind some sort of a >>

permissions wall. > > SHOW. US.

I got tired of fighting with it Greg, so I did install #32 and installed
gnome_desktop (that was new) and xfce4 during the install, and
now things including the screen colors are back to normal,

I've installed the brother printers and scanner drivers and I can modify t
them by the usual rules. I also set a root pw in addition to adding myself
to /etc/group in the appropriate places.

   ↑

On Thu 07 Dec 2023 at 20:49:19 (-0500), gene heskett wrote:

On 12/7/23 20:24, Greg Wooledge wrote:

On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote:

Thats bug #1. Single for rescue demands a root pw.


This isn't a bug.  It's just how things *are*.

People who choose not to set a root password are simply setting themselves
up for this failure.  It *will* happen eventually.  I strongly recommend
setting a root password on your systems.  And you should either *use* it
once in a while, so you don't forget what it is, or else make it the same
as your regular account's password.  So you don't forget what it is.

If you *still* choose not to set a root password, then you will need to
know how to get around the issue you ran into.  You won't be able to use
single-user mode to rescue your system, so you'll need other ways.  There
are two straightforward alternatives: boot from external media (USB or CD
or DVD), or learn how to do the "init=/bin/bash" thing from your boot
loader, which includes bind-mounting /proc and /dev and so on.

.

I've now set a root pw, about 34 chars, so they'll be a couple eons
guessing it AND (horrors) have written it down.


As you set a root password on at least one machine a year ago, can you
just check that you now have a root password on all your machines,
before we have threads like this for each machine, and Greg gets hoarse.

Cheers,
David.

I have not set a root pw on any other wintel machines, they are all 
running buster because the newer python broke LinuxCNC till just 
recently.  All my arms do have it set. They are all running a late 
summer armbian jammy w/xfce4. No video on the early fall versions.



.


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

Re: user perms

[David Wright]

On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:
> On 6/13/22 14:36, Greg Wooledge wrote:
> > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
> > I appear as user 1000 seem to be stuck behind some sort of a >>
> permissions wall. > > SHOW. US.
> 
> I got tired of fighting with it Greg, so I did install #32 and installed
> gnome_desktop (that was new) and xfce4 during the install, and
> now things including the screen colors are back to normal,
> 
> I've installed the brother printers and scanner drivers and I can modify t
> them by the usual rules. I also set a root pw in addition to adding myself
> to /etc/group in the appropriate places.
  ↑

On Thu 07 Dec 2023 at 20:49:19 (-0500), gene heskett wrote:
> On 12/7/23 20:24, Greg Wooledge wrote:
> > On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote:
> > > Thats bug #1. Single for rescue demands a root pw.
> > 
> > This isn't a bug.  It's just how things *are*.
> > 
> > People who choose not to set a root password are simply setting themselves
> > up for this failure.  It *will* happen eventually.  I strongly recommend
> > setting a root password on your systems.  And you should either *use* it
> > once in a while, so you don't forget what it is, or else make it the same
> > as your regular account's password.  So you don't forget what it is.
> > 
> > If you *still* choose not to set a root password, then you will need to
> > know how to get around the issue you ran into.  You won't be able to use
> > single-user mode to rescue your system, so you'll need other ways.  There
> > are two straightforward alternatives: boot from external media (USB or CD
> > or DVD), or learn how to do the "init=/bin/bash" thing from your boot
> > loader, which includes bind-mounting /proc and /dev and so on.
> > 
> > .
> I've now set a root pw, about 34 chars, so they'll be a couple eons
> guessing it AND (horrors) have written it down.

As you set a root password on at least one machine a year ago, can you
just check that you now have a root password on all your machines,
before we have threads like this for each machine, and Greg gets hoarse.

Cheers,
David.

Re: TBird mail (was: user perms)

[Max Nikulin]

On 07/12/2022 15:02, gene heskett wrote:
And when I find it. the prefs.js file does not contain any of the 
strings mentioned in the reply I quoted and everyone but you have clipped.


Am I to add these below? According to the top of the file, t-bird must 
be stopped before editing as it saves this anew when stopping.


That is why I suggested you to use built-in config editor. Doesn't your 
preferred search engine gives relevant result for "thunderbird config 
editor"?

https://support.mozilla.org/en-US/kb/config-editor

You may bypass looking up for the profile directory and change or 
create any options in Hamburger menu / Settings / Config Editor (at

---^^


the bottom of the page).

Re: TBird mail (was: user perms)

[gene heskett]

On 12/6/22 22:53, Max Nikulin wrote:

On 07/12/2022 06:58, gene heskett wrote:

profiledir:
what or where is this "profiledir:"? after sudo updatedb today, I find 


Querying search engine "thunderbird profile directory" gives
https://support.mozilla.org/en-US/kb/profiles-where-thunderbird-stores-user-data
http://kb.mozillazine.org/Profile_folder_-_Thunderbird

How to find your profile

- Click on the menu button or menu bar.
- From the Help menu, click Troubleshooting Information.
- In the Application Basics section, Profile Directory, click on Open 
Directory.
- The Files window will show the name of the profile as well as the path 
to it.


And when I find it. the prefs.js file does not contain any of the 
strings mentioned in the reply I quoted and everyone but you have clipped.


Am I to add these below? According to the top of the file, t-bird must 
be stopped before editing as it saves this anew when stopping.



user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);


You may bypass looking up for the profile directory and change or create 
any options in Hamburger menu / Settings / Config Editor (at the bottom 
of the page).



Hamburger? does not exist.
Confusing...


.


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
Genes Web page 

Re: TBird mail (was: user perms)

[Max Nikulin]

On 07/12/2022 06:58, gene heskett wrote:

profiledir:
what or where is this "profiledir:"? after sudo updatedb today, I find 


Querying search engine "thunderbird profile directory" gives
https://support.mozilla.org/en-US/kb/profiles-where-thunderbird-stores-user-data
http://kb.mozillazine.org/Profile_folder_-_Thunderbird

How to find your profile

- Click on the menu button or menu bar.
- From the Help menu, click Troubleshooting Information.
- In the Application Basics section, Profile Directory, click on Open 
Directory.
- The Files window will show the name of the profile as well as the path 
to it.



user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);


You may bypass looking up for the profile directory and change or create 
any options in Hamburger menu / Settings / Config Editor (at the bottom 
of the page).

Re: TBird mail (was: user perms)

[Tom Furie]

On Tue, Dec 06, 2022 at 06:58:20PM -0500, gene heskett wrote:

> gene@coyote:~$ locate prefs.js
> /home/amanda/.mozilla/firefox/nz58vim6.default-esr/prefs.js
> /home/gene/.local/share/digikam/QtWebEngine/Default/user_prefs.json
> /home/gene/.local/share/kmail2/QtWebEngine/Default/user_prefs.json
> /home/gene/.local/share/konqueror/QtWebEngine/Default/user_prefs.json
> /home/gene/.local/share/plasmashell/QtWebEngine/Default/user_prefs.json
> /home/gene/.local/share/thumbnail.so/QtWebEngine/Default/user_prefs.json
> /home/gene/.moonchild productions/pale moon/1n4tfecn.default/prefs.js
> /home/gene/.mozilla/firefox/cfkfrtdm.default-esr/prefs.js
> /home/gene/.mozilla/firefox/f8j7d2lj.default-esr/prefs.js
> /home/gene/.thunderbird/f37v8icg.default-default/chrome_debugger_profile/prefs.js
> /home/gene/.thunderbird/f37v8icg.default-default/prefs.js
> /home/gene/bin/firefox/defaults/pref/channel-prefs.js
> /usr/lib/firefox-esr/defaults/pref/channel-prefs.js
> /usr/share/thunderbird/defaults/pref/channel-prefs.js
> 
> I count 8 prefs.js in the above list, so which one is actually being talked
> about here?

I count two in your home directory that refer to Thunderbird, one of
which belongs to what looks like a profile you set up for debugging
Chrome. By a very short process of elimination, that only leaves one
prefs.js of interest.

-- 
True to our past we work with an inherited, observed, and accepted vision of
personal futility, and of the beauty of the world.
-- David Mamet


signature.asc
Description: PGP signature

Re: TBird mail (was: user perms)

[gene heskett]

On 6/18/22 19:26, Chuck Zmudzinski wrote:
Going thru some old email and found I had tagged this message which 
contains some unfinished business someone might clarify now:



On 6/15/22 7:14 AM, Felix Miata wrote:

gene heskett composed on 2022-06-15 06:34 (UTC-0400):


What the heck is this vertical bar it uses for a quote level


That's taken care of here with one or both of these two entries in prefs.js in 
the
profiledir:

what or where is this "profiledir:"? after sudo updatedb today, I find this:
gene@coyote:~$ locate prefs.js
/home/amanda/.mozilla/firefox/nz58vim6.default-esr/prefs.js
/home/gene/.local/share/digikam/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/kmail2/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/konqueror/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/plasmashell/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/thumbnail.so/QtWebEngine/Default/user_prefs.json
/home/gene/.moonchild productions/pale moon/1n4tfecn.default/prefs.js
/home/gene/.mozilla/firefox/cfkfrtdm.default-esr/prefs.js
/home/gene/.mozilla/firefox/f8j7d2lj.default-esr/prefs.js
/home/gene/.thunderbird/f37v8icg.default-default/chrome_debugger_profile/prefs.js
/home/gene/.thunderbird/f37v8icg.default-default/prefs.js
/home/gene/bin/firefox/defaults/pref/channel-prefs.js
/usr/lib/firefox-esr/defaults/pref/channel-prefs.js
/usr/share/thunderbird/defaults/pref/channel-prefs.js

I count 8 prefs.js in the above list, so which one is actually being 
talked about here?


user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);

I haven't noticed whether or not in GUI preferences if either has a counterpart.


I also use this setting to help get rid of the vertical bar:

         user_pref("mailnews.send_plaintext_flowed", false);

and I take care to check Options-> Delivery Format is set to

no such option shows in my current copy here. Makes it kinda hard to check.

"Plain Text Only" before sending a message. 

This is not "sticky" ? s/b :o(>


.


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
Genes Web page 

Re: user perms

[David Wright]

On Fri 17 Jun 2022 at 18:14:41 (-0400), gene heskett wrote:
> On 6/17/22 16:29, Anssi Saari wrote:
> > gene heskett  writes:
> > 
> > > I just did all that, so now I have an /etc/rc.local but not an rc-local
> > > but he changes from rc.local to rc-local in the middle. confusing.
> > > 
> > > So which is it. I originally created an rc.local, changed it to
> > > rc-local, and back with mv.

> > The script file is /etc/rc.local but the systemd service name is
> > rc-local.
> > 
> > > Now, I'm not aware of who heyu runs as, probably gene since I'm the
> > > one running it and there is no user heyu.
> > > 
> > > Now, 2 new questions:
> > > 
> > > So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0,
> > > which has the cm11a on the other side of an fdti adaptor?

> > Since you seem to have the expected permissions for /dev/ttyUSB0 and
> > /dev/ttyUSB1 maybe you could just add gene and nut users to the dialout
> > group? adduser gene dialout and adduser nut dialout.
> > 
> > But if you really want to use rc.local then setting the group to nut
> > for the UPS line /dev/ttyUSB1 would work, so just
> > 
> > chgrp nut /dev/ttyUSB1
> > 
> > And then chgrp gene /dev/ttyUSB0
> > 
> > Hope it helps!

> Absolutely the magic twanger Anssi. I put it all in rc.local, or in
> /etc/group
> then ran rc.local for S&G, checked the devices were changed, restarted
> nut-server and nut-client, works as expected, then ran "heyu info" as me
> and got the expected response.
> 
> Finally, someone was not afraid to answer my questions.

I missed seeing the answer to your first question, at the beginning of
the month, where you asked how to determine which way round the ttyUSBs
have been assigned at boot.¹ I've only seen your reports of unplugging
and replugging the connections each time. I'm afraid that's the question
I was interested in answering by means of the example I gave.

Until you know which is which, you can't reliably assign the port to
TTY in nut (which should set the ownerships itself, shouldn't it?).
I don't know about those for heyu as it's not in Debian at present.

¹ "As a furinstance, I used to be able to cat a /dev/ttyUSB*, which made
   self indentifying which was which easy, cuz if you unplug a cm11a, it
   will send … … …".

Cheers,
David.

Re: TBird mail (was: user perms)

[Chuck Zmudzinski]

On 6/15/22 7:14 AM, Felix Miata wrote:
> gene heskett composed on 2022-06-15 06:34 (UTC-0400):
>
> > What the heck is this vertical bar it uses for a quote level
>
> That's taken care of here with one or both of these two entries in prefs.js 
> in the
> profiledir:
>
>   user_pref("mail.quoteasblock", false);
>   user_pref("mail.quoted_graphical", false);
>
> I haven't noticed whether or not in GUI preferences if either has a 
> counterpart.

I also use this setting to help get rid of the vertical bar:

        user_pref("mailnews.send_plaintext_flowed", false);

and I take care to check Options-> Delivery Format is set to
"Plain Text Only" before sending a message.

Re: user perms

[gene heskett]

On 6/17/22 16:29, Anssi Saari wrote:

gene heskett  writes:


I just did all that, so now I have an /etc/rc.local but not an rc-local
but he changes from rc.local to rc-local in the middle. confusing.

So which is it. I originally created an rc.local, changed it to
rc-local, and back with mv.

The script file is /etc/rc.local but the systemd service name is
rc-local.


Now, I'm not aware of who heyu runs as, probably gene since I'm the
one running it and there is no user heyu.

Now, 2 new questions:

So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0,
which has the cm11a on the other side of an fdti adaptor?

Since you seem to have the expected permissions for /dev/ttyUSB0 and
/dev/ttyUSB1 maybe you could just add gene and nut users to the dialout
group? adduser gene dialout and adduser nut dialout.

But if you really want to use rc.local then setting the group to nut
for the UPS line /dev/ttyUSB1 would work, so just

chgrp nut /dev/ttyUSB1

And then chgrp gene /dev/ttyUSB0

Hope it helps!
Absolutely the magic twanger Anssi. I put it all in rc.local, or in 
/etc/group

then ran rc.local for S&G, checked the devices were changed, restarted
nut-server and nut-client, works as expected, then ran "heyu info" as me
and got the expected response.

Finally, someone was not afraid to answer my questions.

Thank you Anssi, take care and stay well.

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

Re: user perms

[Anssi Saari]

gene heskett  writes:

> I just did all that, so now I have an /etc/rc.local but not an rc-local
> but he changes from rc.local to rc-local in the middle. confusing.
>
> So which is it. I originally created an rc.local, changed it to
> rc-local, and back with mv.

The script file is /etc/rc.local but the systemd service name is
rc-local.

> Now, I'm not aware of who heyu runs as, probably gene since I'm the
> one running it and there is no user heyu.
>
> Now, 2 new questions:
>
> So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0,
> which has the cm11a on the other side of an fdti adaptor?

Since you seem to have the expected permissions for /dev/ttyUSB0 and
/dev/ttyUSB1 maybe you could just add gene and nut users to the dialout
group? adduser gene dialout and adduser nut dialout.

But if you really want to use rc.local then setting the group to nut
for the UPS line /dev/ttyUSB1 would work, so just

chgrp nut /dev/ttyUSB1

And then chgrp gene /dev/ttyUSB0

Hope it helps!

Re: user perms

[David Wright]

On Thu 16 Jun 2022 at 12:22:48 (+0300), Anssi Saari wrote:
> David Wright  writes:
> 
> > As it happens, I find I have (but don't use):
> 
> > $ grep -i ttyusb /lib/udev/rules.d/*
> 
> I actually found this in 50-udev-default.rules:
> 
> KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
>  GROUP="dialout"
> 
> So that should set the group for ttySx and ttyUSBx also to dialout and
> in fact I see exactly that happening in my Debian 11 router which has
> devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4:
> 
> $ ls -l /dev/ttyUSB* /dev/ttyS*
> crw-rw 1 root dialout   4, 64 Jun 13 12:12 /dev/ttyS0
> crw-rw 1 root dialout   4, 65 Jun 13 12:12 /dev/ttyS1
> crw-rw 1 root dialout   4, 66 Jun 13 12:12 /dev/ttyS2
> crw-rw 1 root dialout   4, 67 Jun 13 12:12 /dev/ttyS3
> crw-rw 1 root dialout 188,  0 Jun 13 12:12 /dev/ttyUSB0
> crw-rw 1 root dialout 188,  1 Jun 13 12:12 /dev/ttyUSB1
> crw-rw 1 root dialout 188,  2 Jun 13 12:12 /dev/ttyUSB2
> crw-rw 1 root dialout 188,  3 Jun 13 12:12 /dev/ttyUSB3
> crw-rw 1 root dialout 188,  4 Jun 13 12:12 /dev/ttyUSB4
> 
> I didn't find a rule which sets the perms for these to 0660 but
> something does that for me.
> 
> This rule comes with the udev package itself so it should be always
> installed in a Debian installation.
> 
> Still, it seems for Gene these are overwritten somehow but I don't know
> why or how. I have exactly one USB-to-serial cable I can try to plug in
> and see what happens. However it's a CP210x and I think Gene's stuff is
> FTDI.

I don't have any of these devices, so the closest I can manage is a
mouse that keeps disconnecting and reconnecting every few minutes,
which means it loses its acceleration settings.

I've run

$ udevadm monitor -k -p

and

$ udevadm monitor -u -p

in two xterms, dumping the output to files, and I've kept a copy of
the corresponding kern.log to match up with them. I need to find
time to peruse it all.

I was going to suggest to Gene to run these commands, to see where
the serial numbers of his two devices are given, and which attribute
gives them, as Gene plugs the devices into the ports.

If you have /lib/udev/rules.d/60-serial.rules, which runs after the
above, you can see some more specific rules for ttyUSB[0-9]* devices.
I need to read up on what IMPORT{builtin}="usb_id" does, as that's
a udev rule that I've not used before.

(Actually, /I/ need to read up on stuff like
IMPORT{builtin}="hwdb 
'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{nam
e}:'", …
whatever that does, from 70-mouse.rules.)

But it looks as if a file /etc/udev/rules.d/60-serial.rules
could be coerced into creating symlinks called /dev/
for each device (solves the "swapping" problem), and setting
the group/permissions for the ttyUSBn itself. Of course, we
don't know what permissions /do/ work yet, from Gene's posts.

Gene needs to copy that file, and add a simple rule to do something,
anything, to check it works, like touching a file or creating a
symlink (named with a timestamp). Gene might get a feel for how udev
operates, by doing something simple like that.

Cheers,
David.

Re: user perms

[gene heskett]

On 6/16/22 05:25, Anssi Saari wrote:

David Wright  writes:


As it happens, I find I have (but don't use):
$ grep -i ttyusb /lib/udev/rules.d/*

I actually found this in 50-udev-default.rules:

KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", 
GROUP="dialout"

So that should set the group for ttySx and ttyUSBx also to dialout and
in fact I see exactly that happening in my Debian 11 router which has
devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4:

$ ls -l /dev/ttyUSB* /dev/ttyS*
crw-rw 1 root dialout   4, 64 Jun 13 12:12 /dev/ttyS0
crw-rw 1 root dialout   4, 65 Jun 13 12:12 /dev/ttyS1
crw-rw 1 root dialout   4, 66 Jun 13 12:12 /dev/ttyS2
crw-rw 1 root dialout   4, 67 Jun 13 12:12 /dev/ttyS3
crw-rw 1 root dialout 188,  0 Jun 13 12:12 /dev/ttyUSB0
crw-rw 1 root dialout 188,  1 Jun 13 12:12 /dev/ttyUSB1
crw-rw 1 root dialout 188,  2 Jun 13 12:12 /dev/ttyUSB2
crw-rw 1 root dialout 188,  3 Jun 13 12:12 /dev/ttyUSB3
crw-rw 1 root dialout 188,  4 Jun 13 12:12 /dev/ttyUSB4

I didn't find a rule which sets the perms for these to 0660 but
something does that for me.

This rule comes with the udev package itself so it should be always
installed in a Debian installation.

Still, it seems for Gene these are overwritten somehow but I don't know
why or how. I have exactly one USB-to-serial cable I can try to plug in
and see what happens. However it's a CP210x and I think Gene's stuff is

>FTDI

Yes, I had so much trouble with prolific crap I eventually threrw it away.

$40 1998 dollars for junk. At Radio Shack of course. :(
And I wish someone could tell me how to fix tbirds busted quoting, I wrote
what starts with "yes" above and "I" CANNOT remove the quoting that 
looks like
Anssi Saari wrote it. tbird is buggier than 10 day old road kill in 
August! I

just did fix it, but extensive keyboard calisthentics were required.

Thanks Anssi Saari, take care & stay well.

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

Re: user perms

[gene heskett]

On 6/16/22 03:58, Anssi Saari wrote:

gene heskett  writes:


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

Just a note, in my end your post is just text:
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Not HTML, not multipart/alternative with one part text and one HTML. I
don't know if there's any filtering in-between, I read this list via
Gmane's NNTP server.


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.

Debian 11 packages memtest86 and memtest86+ in the main repository with
those package names exactly. Those are quite old and if you managed a
UEFI installation they aren't bootable.


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.

The commercial memtest86 v9 Pro from Passmark goes for $44 today. They
have a free edition too with limited features.

I now have that one installed on an sd card in a reader, works fine.
I rebooted, found it in the bios, and ran it one pass, no errors.

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 looked into this and I have a draft of another post about that but
basically it looks like it'll amount to just "I don't know why" and "it
works for me." I need to test a few things though.

A rude hack to fix the permissions would be to setup /etc/rc.local and
do your chgrps and/or chmods in there. Instructions at

https://blog.wijman.net/enable-rc-local-in-debian-bullseye/ for example.

I just did all that, so now I have an /etc/rc.local but not an rc-local
but he changes from rc.local to rc-local in the middle. confusing.

So which is it. I originally created an rc.local, changed it to 
rc-local, and back with mv.

But a
root@coyote:/etc# systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
 Loaded: loaded (/lib/systemd/system/rc-local.service; 
enabled-runtime; vendor preset: enabled)

    Drop-In: /usr/lib/systemd/system/rc-local.service.d
 └─debian.conf
 Active: active (exited) since Thu 2022-06-16 07:50:14 EDT; 19min ago
   Docs: man:systemd-rc-local-generator(8)
    Process: 49522 ExecStart=/etc/rc.local start (code=exited, 
status=0/SUCCESS)

    CPU: 764us

Jun 16 07:50:14 coyote systemd[1]: Starting /etc/rc.local Compatibility...
Jun 16 07:50:14 coyote systemd[1]: Started /etc/rc.local Compatibility.

Which looks good. So now I put what I want in which file? in this rc.local?
or do I create an rc-local and put the needed chowns, chgrps chmods in
yet another new file?

What I have done is unplugged them in order to delete the /dev entries,
so an ls -l /dev/ttyUSB* returns this:
ls: cannot access '/dev/ttyUSB*': No such file or directory

Then I plugged  them back in, getting this for an ls -l /dev/ttyUSB*
root@coyote:/etc# ls -l /dev/ttyUSB*
crw-rw 1 root dialout 188, 0 Jun 16 08:18 /dev/ttyUSB0
crw-rw 1 root dialout 188, 1 Jun 16 08:18 /dev/ttyUSB1

Now, I'm not aware of who heyu runs as, probably gene since I'm the
one running it and there is no user heyu.

Now, 2 new questions:

So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0,
which has the cm11a on the other side of an fdti adaptor?

Then:
root@coyote:/etc# grep nut group
nut:x:122:
root@coyote:/etc# grep nut passwd
nut:x:115:122::/var/lib/nut:/usr/sbin/nologin

So what do I put in this rc.local to enable nut to use /dev/ttyUSB1, 
which is

an APC 1500 UPS.

Both are returning no perms errors now
gene@coyote:~$ heyu info
starting heyu_relay
HEYU: Can't open tty line.  Check the permissions.

Re: user perms

[Anssi Saari]

David Wright  writes:

> As it happens, I find I have (but don't use):

> $ grep -i ttyusb /lib/udev/rules.d/*

I actually found this in 50-udev-default.rules:

KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
 GROUP="dialout"

So that should set the group for ttySx and ttyUSBx also to dialout and
in fact I see exactly that happening in my Debian 11 router which has
devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4:

$ ls -l /dev/ttyUSB* /dev/ttyS*
crw-rw 1 root dialout   4, 64 Jun 13 12:12 /dev/ttyS0
crw-rw 1 root dialout   4, 65 Jun 13 12:12 /dev/ttyS1
crw-rw 1 root dialout   4, 66 Jun 13 12:12 /dev/ttyS2
crw-rw 1 root dialout   4, 67 Jun 13 12:12 /dev/ttyS3
crw-rw 1 root dialout 188,  0 Jun 13 12:12 /dev/ttyUSB0
crw-rw 1 root dialout 188,  1 Jun 13 12:12 /dev/ttyUSB1
crw-rw 1 root dialout 188,  2 Jun 13 12:12 /dev/ttyUSB2
crw-rw 1 root dialout 188,  3 Jun 13 12:12 /dev/ttyUSB3
crw-rw 1 root dialout 188,  4 Jun 13 12:12 /dev/ttyUSB4

I didn't find a rule which sets the perms for these to 0660 but
something does that for me.

This rule comes with the udev package itself so it should be always
installed in a Debian installation.

Still, it seems for Gene these are overwritten somehow but I don't know
why or how. I have exactly one USB-to-serial cable I can try to plug in
and see what happens. However it's a CP210x and I think Gene's stuff is
FTDI.

Re: user perms

[Anssi Saari]

gene heskett  writes:

> 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

Just a note, in my end your post is just text:
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Not HTML, not multipart/alternative with one part text and one HTML. I
don't know if there's any filtering in-between, I read this list via
Gmane's NNTP server.

> 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.

Debian 11 packages memtest86 and memtest86+ in the main repository with
those package names exactly. Those are quite old and if you managed a
UEFI installation they aren't bootable.

> 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.

The commercial memtest86 v9 Pro from Passmark goes for $44 today. They
have a free edition too with limited features.

> 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 looked into this and I have a draft of another post about that but
basically it looks like it'll amount to just "I don't know why" and "it
works for me." I need to test a few things though.

A rude hack to fix the permissions would be to setup /etc/rc.local and
do your chgrps and/or chmods in there. Instructions at

https://blog.wijman.net/enable-rc-local-in-debian-bullseye/ for example.

Re: user perms

[gene heskett]

rt-types.rules:#  ttyUSB0 (if #0): 
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB1 (if #1): GPS 
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB2 (if #2): AT 
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB3 (if #3): AT 
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB0 (if #0): 
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB1 (if #1): GPS 
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB2 (if #2): AT 
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB3 (if #3): AT 
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB0 (if #0): 
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB1 (if #1): GPS 
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB2 (if #2): AT 
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB3 (if #3): AT 
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB0 (if #0): 
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB1 (if #1): GPS 
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB2 (if #2): AT 
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB3 (if #3): AT 
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB0 (if #0): 
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB1 (if #1): GPS 
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB2 (if #2): AT 
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:#  ttyUSB3 (if #3): AT 
secondary port

looks the same to me.
And an ls -l /dev/ttyUSB* gives this:
gene@coyote:~/.heyu$ ls -l /dev/ttyUSB*
crw-rw 1 root dialout 188, 0 Jun 15 15:17 /dev/ttyUSB0
crw-rw 1 root dialout 188, 1 Jun 15 12:22 /dev/ttyUSB1

 heyu's x10config has TTY=/dev/ttyUSB0,
 gene@coyote:~/.heyu$ grep -i ttyusb x10config
TTY    /dev/ttyUSB0

but heyu runs as me since I compiled it and root installed it

And:
gene@coyote:~/.heyu$ but a "heyu info" (which should
return a list of the 16 house A addresses, their state,
and the cm11a clock time ad battery status)

but "heyu info" returns:
HEYU: Can't open tty line.  Check the permissions.

Nut was installed from the bullseye repo, and it is
in the next boat over, using /dev/ttyUSB1, AND
saying Check the permissions.

I just changed those 2 devices to gene:gene, and
0777 which should have fixed heyu, but it didn't
so I put it back to original. So the problem after the 32nd install,
and 2 reboots because I downloaded the memtest86, v9.4 free
version put it on a sd card in a card reader, and ran it one pass
with zero errors, and the perms problem now seems to have
escalated. AppArmor is installed, is it now a 2nd cause for a
perms denial?

I think the packages they belong to are installed just as Recommends.

[ … snipped stuff about solder and email ?fonts … ]

Cheers,
David.

Take care and stay well, David.

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

Re: user perms

[David Wright]

On Wed 15 Jun 2022 at 06:34:41 (-0400), gene heskett wrote:
> On 6/15/22 01:00, David Wright wrote:

What I wrote is slipping into a morass of IDK what.

> And I'm going to snip down to what I'm replying to, I think.

Yes, I'll join you in snipping.

[ … snipped stuff about email quoting … ]

> 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*.

Anyone reading this list can see this is not true.

> 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 don't understand the concept of "using up" uptime. Surely
uptime just carries on ad infinitum until you have some downtime.

[ … snipped stuff about pigs and pocket money … ]

[ … snipped stuff about a blind person … ]

[ … snipped recapitulation of screen reader … ]

> > > > > 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.

Of course it doesn't, /as of now/. I see no evidence of your having
written the necessary file to tell udev to do what you want it to do.
Until you write it, "It does not!".

Look, if I write:

  Here's how I make udev do X for me. Now you make it do Y for you
  in the same manner, using my example and the system's examples
  to help you,

there's no point in screaming that a) your question has fallen on
deaf ears for a decade, b) I haven't fixed your problem for you.

> 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

Duh—yes, that's what the current rules on your system specify
that it should do, I suppose (I ain't there to look see).

> 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.

It's not a "fix". You don't zap, or nuke, some file. You
write a bit of code (that's what the rules look like) to
tell it what you want doing. Like I did. That's what my
example is for. As they used to say on children's
TV 60 years ago, "Now /you/ try it".

Or if you're very lucky, you find something sufficiently alike
that you can copy the file under /etc/, and your modified
version will overrule the original file under /lib/.

Do you need telling that "your modified version" becomes
"your modified version" by your modifying it, and not by
magic just because I told you to copy it from /lib/ to /etc/.

> > /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.

Well, there might not be, if you don't install anything that requires
those sorts of devices to be configured. Debian doesn't see the need
to include hundreds of configuration files for no particular reason.

You could try installing a few serial-ish packages to see what turns
up, or you could google for any mention of these files.

As it happens, I find I have (but don't use):

$ grep -i ttyusb /lib/udev/rules.d/*
/lib/udev/rules.d/40-usb_modeswitch.rules:# Adds a symlink "gsmmodem[n]" to the 
lowest ttyUSB port with interrupt
/lib/udev/rules.d/40-usb_modeswitch.rules:KERNEL=="ttyUSB*", 
ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p 
%s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
/lib/udev/

Re: memtest (was: user perms)

[tomas]

On Wed, Jun 15, 2022 at 07:26:25AM -0400, Felix Miata wrote:
> gene heskett composed on 2022-06-15 06:34 (UTC-0400):
> 
> > 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.
> 
> I don't even try to use FOSS memtest86+ on UEFI PCs. Instead, I use the free
> version [...]

For those who care, "free" seems here to mean "free of cost", not
"free software". The website weasels around this point (which is
somewhat irritating).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: memtest (was: user perms)

[Felix Miata]

gene heskett composed on 2022-06-15 06:34 (UTC-0400):

> 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.

I don't even try to use FOSS memtest86+ on UEFI PCs. Instead, I use the free
version of the proprietary memtest86 from https://www.memtest86.com/. I run it
from this Grub stanza in /boot/grub/custom.cfg on my fastest/newest x86_64 PC:

menuentry "memtest86 7.4 EFI" {
search --no-floppy --label --set=root TM8P01ESP
chainloader /mt74x64.efi
}

That menu entry is pointing to the FAT32 ESP partition, which has the filesystem
label TM8P01ESP.

The current free version is much newer than 7.4.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: TBird mail (was: user perms)

[Felix Miata]

gene heskett composed on 2022-06-15 06:34 (UTC-0400):

> What the heck is this vertical bar it uses for a quote level

That's taken care of here with one or both of these two entries in prefs.js in 
the
profiledir:

user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);

I haven't noticed whether or not in GUI preferences if either has a counterpart.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: user perms

[gene heskett]

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
sigh

Re: user perms

[David Wright]

On Tue 14 Jun 2022 at 18:20:15 (-0400), gene heskett wrote:
> On 6/14/22 13:25, David Wright wrote:
> > On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:
> > > On 6/13/22 14:36, Greg Wooledge wrote:
> > > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
> > > > I appear as user 1000 seem to be stuck behind some sort of a >>
> > > permissions wall. > > SHOW. US.
> > > 
> > > I got tired of fighting with it Greg, so I did install #32 and installed
> > > gnome_desktop (that was new) and xfce4 during the install, and
> > > now things including the screen colors are back to normal,
> > > 
> > > I've installed the brother printers and scanner drivers and I can modify t
> > > them by the usual rules. I also set a root pw in addition to adding myself
> > > to /etc/group in the appropriate places. I created an /sshnet tree with 
> > > the
> > > other 5 machines here, did a root chown -R me:me on that path and just now
> > > mounted all of them as me, so I own the path to me on the other 5 
> > > machines.

> > "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.
> > 
> > > And my working environment is getting close to completed, something
> > > that only been workable occasionally since that last Seagate 2T drive
> > > went tits down in the night last Dec 8th.
> > > 
> > > Kmail5 is buggier than road kill in June, but t-bird is more like
> > > August, so
> > > I'm looking for a mailer that actually works. tbirds sort filters
> > > don't, and
> > > they think everybody uses only html, so word wrap doesn't work So I'm
> > > doing this by hand..
> > > 
> > > 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.
> > 
> > > Same perms story for heyu and nut,
> > > but some somebody, thinking security as opposed to usability, insists
> > > on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can
> > > get past that to get their job done. And IF I reset those two devices
> > > to 0777,
> > > re reboot fixes that.
> > > 
> > > 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:
> > 
> > $ 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.

> > > I just did,

> > 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 fro

Re: user perms

[gene heskett]

On 6/14/22 13:25, David Wright wrote:

On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:

On 6/13/22 14:36, Greg Wooledge wrote:

On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
I appear as user 1000 seem to be stuck behind some sort of a >>

permissions wall. > > SHOW. US.

I got tired of fighting with it Greg, so I did install #32 and installed
gnome_desktop (that was new) and xfce4 during the install, and
now things including the screen colors are back to normal,

I've installed the brother printers and scanner drivers and I can modify t
them by the usual rules. I also set a root pw in addition to adding myself
to /etc/group in the appropriate places. I created an /sshnet tree with the
other 5 machines here, did a root chown -R me:me on that path and just now
mounted all of them as me, so I own the path to me on the other 5 machines.

"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.


And my working environment is getting close to completed, something
that only been workable occasionally since that last Seagate 2T drive
went tits down in the night last Dec 8th.

Kmail5 is buggier than road kill in June, but t-bird is more like
August, so
I'm looking for a mailer that actually works. tbirds sort filters
don't, and
they think everybody uses only html, so word wrap doesn't work So I'm
doing this by hand..

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.


Same perms story for heyu and nut,
but some somebody, thinking security as opposed to usability, insists
on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can
get past that to get their job done. And IF I reset those two devices
to 0777,
re reboot fixes that.

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:

$ 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.

I just did,

As usual, we don't know what you actually did to handle it.


yes I did, but you snipped that part. How convenient...
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.

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.

but haven't changed the perms of /dev/ttyUSB* yet.

Of course, the idea was that /you/ don't have to do tha

Re: user perms

[Joe]

On Mon, 13 Jun 2022 19:03:47 -0400
gene heskett  wrote:


> 
> Kmail5 is buggier than road kill in June, but t-bird is more like 
> August, so
> 
> I'm looking for a mailer that actually works. tbirds sort filters
> don't, and
> 
> they think everybody uses only html, so word wrap doesn't work So I'm
> 
> doing this by hand..

Have you tried Claws-mail? It used to be a bit buggy, but usable, but
I haven't had any trouble for quite a while (the remaining bugs are
well-hidden). I switched to it when I finally tired of waiting for TB
to wake up and do things, it was cheaper than buying a faster computer.
> 
> 
> 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
> 
I haven't installed MS Office for a while, but last time I did, it
required root privileges on the first run, as all previous versions
have done. A user file had to be created in a Windows system
directory. It was no good doing it as root, each *user* had to be given
admin privileges for that first run (of each Office component) and if
the IT admin isn't allowed to know the users' passwords (as he
shouldn't be) this required the presence of the user, at least to log
on. In an office where anyone may log on to any computer, that's a
monumental pain. When last I had to do that, there was no centralised
way to do it, even in a domain.

Beat that.

-- 
Joe

Re: user perms

[Brian]

On Tue 14 Jun 2022 at 12:22:05 -0500, David Wright wrote:

> On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:
> > On 6/13/22 14:36, Greg Wooledge wrote:
> > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
> > > I appear as user 1000 seem to be stuck behind some sort of a >>
> > permissions wall. > > SHOW. US.
> > 
> > I got tired of fighting with it Greg, so I did install #32 and installed
> > gnome_desktop (that was new) and xfce4 during the install, and
> > now things including the screen colors are back to normal,
> > 
> > I've installed the brother printers and scanner drivers and I can modify t
> > them by the usual rules. I also set a root pw in addition to adding myself
> > to /etc/group in the appropriate places. I created an /sshnet tree with the
> > other 5 machines here, did a root chown -R me:me on that path and just now
> > mounted all of them as me, so I own the path to me on the other 5 machines.
> 
> "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.

"...appropriate places" is about as fuzzy as it gets. The user appears
to have been put is group lp. This is completely unwanted as it opens
up a security hole. Thank goodness the OP is not managing my machines
(or my TV reception capabilities :) ).

-- 
Brian.

Re: user perms

[Andrew M.A. Cater]

On Tue, Jun 14, 2022 at 12:22:05PM -0500, David Wright wrote:
> On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:
> > On 6/13/22 14:36, Greg Wooledge wrote:
> > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
> > > I appear as user 1000 seem to be stuck behind some sort of a >>
> > permissions wall. > > SHOW. US.
> > 
> > I got tired of fighting with it Greg, so I did install #32 and installed
> > gnome_desktop (that was new) and xfce4 during the install, and
> > now things including the screen colors are back to normal,
> > 
> > I've installed the brother printers and scanner drivers and I can modify t
> > them by the usual rules. I also set a root pw in addition to adding myself
> > to /etc/group in the appropriate places. I created an /sshnet tree with the
> > other 5 machines here, did a root chown -R me:me on that path and just now
> > mounted all of them as me, so I own the path to me on the other 5 machines.
> 
> "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.
> 

adduser gene  

would be the way to do it and have adduser write the file appropriately,
in my experience.

Manually editing /etc/passwd /etc/group or whatever is error-prone, yes.

In the days when Raspbian defaulted to setting a pi user and default group
I'd use the groups command to check whcich groups were set and then
set them by using adduser for my own user, add my own user to the appropriate
group for sudo then, at that point, logout, login as my own user and

 userdel -r pi

> > And my working environment is getting close to completed, something
> > that only been workable occasionally since that last Seagate 2T drive
> > went tits down in the night last Dec 8th.
> > 
> > Kmail5 is buggier than road kill in June, but t-bird is more like
> > August, so
> > I'm looking for a mailer that actually works. tbirds sort filters
> > don't, and
> > they think everybody uses only html, so word wrap doesn't work So I'm
> > doing this by hand..
> > 

Thunderbird and the like do have options to set what they accept and
what they display.

Here, I'm using mutt - but I will admit that I had someone more knowledgeable
help me set up mail forwarding and so on.

Glad to hear you've finally got an environment that more or less works - 
maybe leave it working for more than a week if you possibly can 

All the very best to all on the list, as ever

Andy Cater

Re: user perms

[David Wright]

On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote:
> On 6/13/22 14:36, Greg Wooledge wrote:
> > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >>
> > I appear as user 1000 seem to be stuck behind some sort of a >>
> permissions wall. > > SHOW. US.
> 
> I got tired of fighting with it Greg, so I did install #32 and installed
> gnome_desktop (that was new) and xfce4 during the install, and
> now things including the screen colors are back to normal,
> 
> I've installed the brother printers and scanner drivers and I can modify t
> them by the usual rules. I also set a root pw in addition to adding myself
> to /etc/group in the appropriate places. I created an /sshnet tree with the
> other 5 machines here, did a root chown -R me:me on that path and just now
> mounted all of them as me, so I own the path to me on the other 5 machines.

"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.

> And my working environment is getting close to completed, something
> that only been workable occasionally since that last Seagate 2T drive
> went tits down in the night last Dec 8th.
> 
> Kmail5 is buggier than road kill in June, but t-bird is more like
> August, so
> I'm looking for a mailer that actually works. tbirds sort filters
> don't, and
> they think everybody uses only html, so word wrap doesn't work So I'm
> doing this by hand..
> 
> 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.

> Same perms story for heyu and nut,
> but some somebody, thinking security as opposed to usability, insists
> on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can
> get past that to get their job done. And IF I reset those two devices
> to 0777,
> re reboot fixes that.
> 
> 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:

$ 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.
> 
> I just did,

As usual, we don't know what you actually did to handle it.

> 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.

> 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

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).

Cheers,
David.

Re: user perms

[mick crane]

On 2022-06-14 00:03, gene heskett wrote:

I'm looking for a mailer that actually works. tbirds sort filters 
don't, and


they think everybody uses only html, so word wrap doesn't work So I'm

doing this by hand..


I'd have thought if you've got PCs in different buildings Dovecot, 
Roundcube, Seive on the PC with Apache on it would work for you. Think 
it uses postfix which seems automagically installed.

I like it but really should upgrade.
getmail from https://pyropus.ca./software/getmail/ for getting the mail

mick

Re: perms

[gene heskett]

On 6/13/22 14:49, mick crane wrote:

On 2022-06-13 19:11, Andrew M.A. Cater wrote:

Hi Gene,

For CUPS - you can use lpadmin from a terminal as a command line.

Open a konsole terminal, su - inside it, then use lpadmin


Just looking to see if I could remember how to add a cups printer 
noticed that 


I am in lpadmin group in /etc/group which might be why I look to be able 
to login


as me in cups webpage "add printer".

I just looked, cup was installed when I rebooted this time but 
/etc/group has only an


lp entry, no lpadmin. So I made it like this: "lp:x:7:gene" and it seems 
to have worked.




colours would likely be the colours of the shell and the editor rather 
than the terminal.

I think I did this "select-editor" in mc and was presented with a choice.
https://unix.stackexchange.com/questions/80845/how-to-set-default-editor-viewer-for-midnight-commander-to-sublime 


maybe there are things to do in [colors] section of
~/.config/mc/ini


That also was fixed by a re-install.

Thank you, Take care & stay well, mick

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

Re: user perms

[gene heskett]

On 6/13/22 14:36, Greg Wooledge wrote:
On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:  >> I appear as user 1000 seem to be stuck behind some sort of a >> 

permissions wall. > > SHOW. US.

I got tired of fighting with it Greg, so I did install #32 and installed

gnome_desktop (that was new) and xfce4 during the install, and

now things including the screen colors are back to normal,


I've installed the brother printers and scanner drivers and I can modify t

them by the usual rules. I also set a root pw in addition to adding myself

to /etc/group in the appropriate places. I created an /sshnet tree with the

other 5 machines here, did a root chown -R me:me on that path and just now

mounted all of them as me, so I own the path to me on the other 5 machines.


And my working environment is getting close to completed, something

that only been workable occasionally since that last Seagate 2T drive

went tits down in the night last Dec 8th.

Kmail5 is buggier than road kill in June, but t-bird is more like 
August, so


I'm looking for a mailer that actually works. tbirds sort filters don't, 
and


they think everybody uses only html, so word wrap doesn't work So I'm

doing this by hand..


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.  Same perms story for heyu and nut,

but some somebody, thinking security as opposed to usability, insists

on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can

get past that to get their job done. And IF I reset those two devices to 
0777,


re reboot fixes that.


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.

[...]


You're a goddamned 20+ year Linux veteran.  You should be able to  > handle 
something as ridiculously simple as this.


I just did, but haven't changed the perms of /dev/ttyUSB* yet. 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.

Take care and stay well, Greg.


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

Re: user perms

[Eduardo M KALINOWSKI]

On 13/06/2022 18:39, Felix Miata wrote:

Eduardo M KALINOWSKI composed on 2022-06-13 16:29 (UTC-0400):


And Gene is one of a few users that never help themselves, even when
repeatedly told what to do and what not to do.


Just wait until your wife of 60 years is gone and you're 89. See how you like
having no one there to talk to any more while your memory is fading from memory.
It may be poor excuse, but it isn't something you can expect to go away through
razzing, if ever. Be kind.


At this stage, I cannot rule out the possibility that Gene Heskett is 
actually a social experiment to figure out how far people on debian-user 
will go in trying to help someone that asks for help, and then ignores 
the actual attempts at help received.


Or maybe it's performance art, as someone else observed.

--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: user perms

[Felix Miata]

Eduardo M KALINOWSKI composed on 2022-06-13 16:29 (UTC-0400):

> And Gene is one of a few users that never help themselves, even when 
> repeatedly told what to do and what not to do.

Just wait until your wife of 60 years is gone and you're 89. See how you like
having no one there to talk to any more while your memory is fading from memory.
It may be poor excuse, but it isn't something you can expect to go away through
razzing, if ever. Be kind.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: user perms

[Eduardo M KALINOWSKI]

On 13/06/2022 15:33, Greg Wooledge wrote:

Why the hell do you CONTINUE to make these vague statements with NO
demonstration of what the actual problem is?


And why do you continue asking for the same things, knowing that they 
won't be provided?


Not that your request in invalid - certainly if the user wants actual 
help, they must provided good and accurate details of the problem and of 
what they have tried in order to identify and/or solve the problem.


But the OP in question never provides such details - even after 
repeatedly being asked for them, by you and other equally patient people.


I understand the desire to help, but the user must be willing to help 
themselves - providing details when asked for, showing output of 
diagnostic commands, or just not jumping from unrelated problem to 
unrelated problem in the same conversation.


And Gene is one of a few users that never help themselves, even when 
repeatedly told what to do and what not to do.



--
In the strict scientific sense we all feed on death -- even vegetarians.
-- Spock, "Wolf in the Fold", stardate 3615.4

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: MC settings (was: user perms)

[Felix Miata]

Joe composed on 2022-06-13 20:03 (UTC+0100):

> I don't know if you know this, but when you close mc the *current*
> version of the config file is re-saved. So if you edited the file in
> mc, the new version will be overwritten.

That's an unfortunate default, not carved in stone. Turn off auto save setup and
saving of settings won't happen unless you goto menu and select save.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: perms

[Joe]

On Mon, 13 Jun 2022 19:46:13 +0100
mick crane  wrote:

> On 2022-06-13 19:11, Andrew M.A. Cater wrote:
> > Hi Gene,
> > 
> > For CUPS - you can use lpadmin from a terminal as a command line.
> > 
> > Open a konsole terminal, su - inside it, then use lpadmin  
> 
> Just looking to see if I could remember how to add a cups printer 
> noticed that I am in lpadmin group in /etc/group which might be why I 
> look to be able to login as me in cups webpage "add printer".
> 
> colours would likely be the colours of the shell and the editor
> rather than the terminal.
> I think I did this "select-editor" in mc and was presented with a 
> choice.
> https://unix.stackexchange.com/questions/80845/how-to-set-default-editor-viewer-for-midnight-commander-to-sublime

And those choices are all you get. I've stuck with cooledit.

> maybe there are things to do in [colors] section of
> ~/.config/mc/ini

There most certainly are, but it's a pain, and as I say, if you edit it
in mc and just re-save it, mc will overwrite it with the old file when
it closes.

-- 
Joe

Re: user perms

[Joe]

On Mon, 13 Jun 2022 13:56:12 -0400
gene heskett  wrote:


> I can't modify screen colors in any terminal or in mc, and mc's
> colors are all so alike I can only read a directory list which is in
> a different color, if I want to read a file, I have to use nano.
> 

I don't know if you know this, but when you close mc the *current*
version of the config file is re-saved. So if you edited the file in
mc, the new version will be overwritten.

I edit it in mc, save it under a different name, close mc and rename my
file mc.ini. What I haven't yet found is a means of changing the colour
of comments in files that mc recognises as programs.

-- 
Joe

Re: user perms

[Bijan Soleymani]

On 6/13/2022 2:33 PM, Greg Wooledge wrote:

On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:

I appear as user 1000 seem to be stuck behind some sort of a permissions
wall.

SHOW.  US.

No need to shout in all caps.

Why the hell

no need for language

You're a goddamned 20+ year Linux veteran.  You should be able to handle
something as ridiculously simple as this.

again language and personal attack

I just got an email saying there's a FAQ and a code of conduct.

Bijan

Re: perms

[mick crane]

On 2022-06-13 19:11, Andrew M.A. Cater wrote:

Hi Gene,

For CUPS - you can use lpadmin from a terminal as a command line.

Open a konsole terminal, su - inside it, then use lpadmin


Just looking to see if I could remember how to add a cups printer 
noticed that I am in lpadmin group in /etc/group which might be why I 
look to be able to login as me in cups webpage "add printer".


colours would likely be the colours of the shell and the editor rather 
than the terminal.
I think I did this "select-editor" in mc and was presented with a 
choice.

https://unix.stackexchange.com/questions/80845/how-to-set-default-editor-viewer-for-midnight-commander-to-sublime
maybe there are things to do in [colors] section of
~/.config/mc/ini

mick

Re: user perms

[Greg Wooledge]

On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote:
> I appear as user 1000 seem to be stuck behind some sort of a permissions
> wall.

SHOW.  US.

Why the hell do you CONTINUE to make these vague statements with NO
demonstration of what the actual problem is?

It would take you FIVE SECONDS to paste the offending results from your
terminal to the email you're already writing.

Anyway, if you're seeing "1000" instead of "gene" in the output of some
command such as "ls -ld ~" then it's probably your /etc/passwd file being
broken in some way.  Permissions on the file.  Contents of the file.
Permissions on the directories leading up to the file (/ and /etc).
One of those things.

Whatever it is, fix it.

You're a goddamned 20+ year Linux veteran.  You should be able to handle
something as ridiculously simple as this.

Re: perms

[Andrew M.A. Cater]

Hi Gene,

For CUPS - you can use lpadmin from a terminal as a command line.

Open a konsole terminal, su - inside it, then use lpadmin

For the other issues: if you really want to do another install, go ahead
- this time, maybe try UEFI ? 

All the very best, as ever,

Andy Cater

user perms

[gene heskett]

Greetings all;

I appear as user 1000 seem to be stuck behind some sort of a permissions 
wall.


I can't modify screen colors in any terminal or in mc, and mc's colors are all 
so alike I can
only read a directory list which is in a different color, if I want to read a 
file, I have to use nano.

I've installed cups which wasn't before along with the brother drivers for my 
two printers,
but they aren't configured, so I installed apache2 to use localhost:631 to set 
them up, firefox won't
run as root and cups is denying me permissions to do anything to the displayed 
printers its finding,
without asking me for a pw.

So obviously, something is wrong. I am a member of the sudo group and the lp 
group.

Do I have to do a 32nd install so it all hopefully gets fixed so I can actually 
do something?

hanks for any ideas.

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

Re: nother problem I can't access my crontab, no perms

[Étienne Mollier]

On 5/20/19 8:40 PM, Gene Heskett wrote:
>> I would tend to believe that execution of "crontab" related
>> commands will benefit from the proper UIDs when operating.  On
>> my machine, at the same working directory, I have:
>>
>>  $ sudo ls -lR
>>  .:
>>  total 0
>>  drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs
>>
>>  ./crontabs:
>>  total 4
>>  -rw--- 1 user crontab 381 Feb 28 22:49 user
>>
>> It would seem that your restore attempt conserved UIDs, but
>> crontab's former UID has become systemd-timesyncd one.  Perhaps
>> a well placed `chgrp -R crontab crontabs/` will do?

Whoopsie, for the sake of precision, I mostly meant GID (Group
Identifier) instead of UID (User Identifier).

> Absolutely spot on,  Étienne Mollier, thank you very much.  Now cron has 
> about 2 weeks work to catch up on. :)

Glad to read that  :)
-- 
Étienne Mollier 

Re: nother problem I can't access my crontab, no perms

[Gene Heskett]

On Monday 20 May 2019 02:21:20 pm Étienne Mollier wrote:

> Good Day Gene,
>
> On coyote, /var/spool/cron contained:
> > drwx-wx--T  2 root   systemd-timesync 4096 Mar 31 09:15 crontabs
>
>  ^^^
> You can't go through this "crontab" directory if you are not
> root, or a member of the group systemd-timesync.  That includes
> that you can't read any file below, even if it is attributed to
> you.
>
> I would tend to believe that execution of "crontab" related
> commands will benefit from the proper UIDs when operating.  On
> my machine, at the same working directory, I have:
>
>   $ sudo ls -lR
>   .:
>   total 0
>   drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs
>
>   ./crontabs:
>   total 4
>   -rw--- 1 user crontab 381 Feb 28 22:49 user
>
> It would seem that your restore attempt conserved UIDs, but
> crontab's former UID has become systemd-timesyncd one.  Perhaps
> a well placed `chgrp -R crontab crontabs/` will do?
>
> Kind Regards,

Absolutely spot on,  Étienne Mollier, thank you very much.  Now cron has 
about 2 weeks work to catch up on. :)

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)
Genes Web page 

Re: nother problem I can't access my crontab, no perms

[Étienne Mollier]

Good Day Gene,

On coyote, /var/spool/cron contained:
> drwx-wx--T  2 root   systemd-timesync 4096 Mar 31 09:15 crontabs
 ^^^
You can't go through this "crontab" directory if you are not
root, or a member of the group systemd-timesync.  That includes
that you can't read any file below, even if it is attributed to
you.

I would tend to believe that execution of "crontab" related
commands will benefit from the proper UIDs when operating.  On
my machine, at the same working directory, I have:

$ sudo ls -lR
.:
total 0
drwx-wx--T 2 root crontab 21 Feb 28 22:49 crontabs

./crontabs:
total 4
-rw--- 1 user crontab 381 Feb 28 22:49 user

It would seem that your restore attempt conserved UIDs, but
crontab's former UID has become systemd-timesyncd one.  Perhaps
a well placed `chgrp -R crontab crontabs/` will do?

Kind Regards,
-- 
Étienne Mollier 

Re: nother problem I can't access my crontab, no perms

[Gene Heskett]

On Monday 20 May 2019 11:58:45 am Gene Heskett wrote:

> Gut an ls -lR of /var/spool shows they are an exact copy of the wheezy
> files. With mine own by me.
>
> What did I screw up now. I had noticed my kmail spam folder was
> filling up because my cron scripts aren't running as scheduled. 
> Otherwise I haven't touched it since installing stretch.
>
> Any clues? Making me a member of the group shown made no diff, and it
> worked a treat under wheezy.
>
> Cheers, Gene Heskett
An ls -laR of /var/spool/cron:
ene@coyote:/var/spool/cron$ sudo  ls -laR
.:
total 20
drwxr-xr-x  5 root   root 4096 Feb  3  2015 .
drwxr-xr-x 10 root   root 4096 May 10 02:27 ..
drwxrwx--T  2 daemon daemon   4096 Feb  3  2015 atjobs
drwxrwx--T  2 daemon daemon   4096 Oct  3  2014 atspool
drwx-wx--T  2 root   systemd-timesync 4096 Mar 31 09:15 crontabs

./atjobs:
total 12
drwxrwx--T 2 daemon daemon 4096 Feb  3  2015 .
drwxr-xr-x 5 root   root   4096 Feb  3  2015 ..
-rw--- 1 daemon daemon2 Nov  5  2014 .SEQ

./atspool:
total 8
drwxrwx--T 2 daemon daemon 4096 Oct  3  2014 .
drwxr-xr-x 5 root   root   4096 Feb  3  2015 ..

./crontabs:
total 24
drwx-wx--T 2 root systemd-timesync 4096 Mar 31 09:15 .
drwxr-xr-x 5 root root 4096 Feb  3  2015 ..
-rw--- 1 amanda   systemd-timesync  281 Nov 16  2018 amanda
-rw--- 1 gene systemd-timesync 1430 Aug  2  2018 gene
-rw--- 1 root systemd-timesync  662 Mar 31 09:15 root
-rw--- 1 www-data systemd-timesync 1117 Jul 22  2017 www-data

Looks good to me , but strace says I can't open the file "gene"


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)
Genes Web page 

nother problem I can't access my crontab, no perms

[Gene Heskett]

Gut an ls -lR of /var/spool shows they are an exact copy of the wheezy 
files. With mine own by me.

What did I screw up now. I had noticed my kmail spam folder was filling 
up because my cron scripts aren't running as scheduled.  Otherwise I 
haven't touched it since installing stretch.

Any clues? Making me a member of the group shown made no diff, and it 
worked a treat under wheezy.
 
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)
Genes Web page 

Re: Qs re: ActiveDirectory authentication & perms

[Kent West]

On Tue, May 23, 2017 at 12:42 PM, George42  wrote:

> Kent West wrote:
>
> > I'm not quite sure what questions to ask...
> >
> > I have a Debian box used by 10 or 12 people on a university campus;
>
> ... snip...
>
> > After considerable hair-pulling, I've managed to get the box to
> > authenticate using their AD credentials,
>
> ... snip ...
>
> > Since it's just a dozen users or so, I can easily "id" their AD UID
> > and "chown -R" their files in their home directory (which have been
> > copied over manually from the old Debian box) to their AD UID.
> >
> > But that leaves several questions:
> >
> > 1) If I just "chown -R", that changes the ownership of all the files,
> > regardless how the files may have been set-up on the old box. For
> > example, I notice in at least one web directory for one user, the
> > files were owned by www-data, with the group ownership set to the
> > group name corresponding to the user's name on the old box. Changing that
> > ownership from "www-data" to "joe_user" might break things. Is there a
> way
> > to just chown the ownership of files already owned by the old username?
>
> You should be able to use a combination of find and xargs to chown only
> files
> owned by a certain user. This command should be approximately what you
> want:
>
> find /home/username -user local_user -print0 | xargs -0 chown ad_user
>


I found this same (essentially) answer about an hour ago, in this form:

find /home -user local_user -exec chown ad_user {} \;

This seems to have worked. I'm not sure if your method might or might not
be better, but I appreciate you giving a good answer.



> > 2) The group that all the AD-authenticated users are in is "domain
> users".
> > That means that any files formerly owned by suzy:suzy are now owned by
> > suzy:"domain users", and if a file is set to 770 (or similar), any one
> > of the people logging in can access any other person's files as a
> > member of that group. Not good.
>
> In that case, you will have to either change the file permissions to 700
> or change the group on the files.
>
> > 2a) What's the best route for dealing with this group ownership issue?
> > Can I remap the group for all AD-authenticated users to be their own
> > username, like it was in the old Debian setup? Is that even a good idea?
>
> If the files should be accessible only by the user who owns them, then you
> could set the permissions to 700. No need to create groups. That is what I
> would do. The main thing will be to set up a create mask for new files.
> Changing owner on the existing files shouldn't set the group to "domain
> users"
> unless you tell it to.
>
> In order to have groups that match the usernames, you would have to create
> them manually. AD setups that I am familiar with do not have a group for
> each user like a local Linux system typically does. I would recommend
> against this. It will be extra work, extra clutter and not as clear from
> an admin point of view since it is not normally done.
>

Again, I found out about an hour ago that AD doesn't have a group for each
user:

from
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/groupmapping.html

"Windows does not permit user and group accounts to have the same name.
This has serious implications for all sites that use private group
accounts. A private group account is an administrative practice whereby
users are each given their own group account. Red Hat Linux, as well as
several free distributions of Linux, by default create private groups."

I at first tried to manually create a group for each user (using only a
couple as tests), but found that doesn't work because the group name in
/etc/groups is not recognized when using the AD setup.

So I decided I'd have to chown the ownership of all the files to 700 (just
as you've now suggested, which validates that I'm thinking along the right
direction) and figure out how to set the perms by default on new files
created. Your mentioning of a "mask for new files" sounds just like what I
need to look up next (from vague memory from long ago, it seems it's an
easy fix - ah, 30 seconds of googling just now points me to "umask"; I'll
study another few minutes in a few minutes, and have it working in a few
minutes, I bet).

Not having group membership the same as the owner membership will be a new
way of thinking for me, but I bet I can wrap my brain around it.



> > 2b) I'm skittish of having spaces in group names (or files, etc), and
> > would rather that "domain users" be something

Re: Qs re: ActiveDirectory authentication & perms

[George42]

Kent West wrote:

> I'm not quite sure what questions to ask...
>
> I have a Debian box used by 10 or 12 people on a university campus;

... snip...

> After considerable hair-pulling, I've managed to get the box to
> authenticate using their AD credentials,

... snip ...

> Since it's just a dozen users or so, I can easily "id" their AD UID
> and "chown -R" their files in their home directory (which have been
> copied over manually from the old Debian box) to their AD UID.
>
> But that leaves several questions:
>
> 1) If I just "chown -R", that changes the ownership of all the files,
> regardless how the files may have been set-up on the old box. For
> example, I notice in at least one web directory for one user, the
> files were owned by www-data, with the group ownership set to the
> group name corresponding to the user's name on the old box. Changing that
> ownership from "www-data" to "joe_user" might break things. Is there a way
> to just chown the ownership of files already owned by the old username?

You should be able to use a combination of find and xargs to chown only files
owned by a certain user. This command should be approximately what you want:

find /home/username -user local_user -print0 | xargs -0 chown ad_user

> 2) The group that all the AD-authenticated users are in is "domain users".
> That means that any files formerly owned by suzy:suzy are now owned by
> suzy:"domain users", and if a file is set to 770 (or similar), any one
> of the people logging in can access any other person's files as a
> member of that group. Not good.

In that case, you will have to either change the file permissions to 700
or change the group on the files.

> 2a) What's the best route for dealing with this group ownership issue?
> Can I remap the group for all AD-authenticated users to be their own
> username, like it was in the old Debian setup? Is that even a good idea?

If the files should be accessible only by the user who owns them, then you
could set the permissions to 700. No need to create groups. That is what I
would do. The main thing will be to set up a create mask for new files.
Changing owner on the existing files shouldn't set the group to "domain users"
unless you tell it to.

In order to have groups that match the usernames, you would have to create
them manually. AD setups that I am familiar with do not have a group for
each user like a local Linux system typically does. I would recommend
against this. It will be extra work, extra clutter and not as clear from
an admin point of view since it is not normally done.

> 2b) I'm skittish of having spaces in group names (or files, etc), and
> would rather that "domain users" be something like "domain_users";
> does the AD authentication process have some way of remapping that
> name to one without spaces? (Or this may be a moot question, depending
> on the answer to 2a above.)

You would have to look at the documentation for the AD authentication
process that you are using. I have never seen such a thing. I have been using
sssd to authenticate against AD for a little while now and the only issue I
have run into with the spaces was trying to limit ssh access based on a group
that had a space. For the most part, don't worry about the spaces. If something
doesn't work with a group that has a space, check the documentation for the
particular command. Usually you either enclose it in quotes or use a \ to
escape the space.

> 3) Can I limit logins/file-sharing to just a subset of campus users
> (one department, not just anyone having a campus account)?

It seems based on your next message you figured out a way.

> 4) I haven't even begun to think about how to tie this into their
> samba (or is it "cifs" nowadays?) file shares. Any pointers dealing
> with that would be appreciated.

It all depends on how you set up samba. If you want to know how things
affect your samba configuration, then you need to learn how to configure
samba so that you understand the configuration you are using.

Hope that helps some.

- george

Re: Qs re: ActiveDirectory authentication & perms

[Kent West]

On Mon, May 22, 2017 at 9:59 AM, Kent West  wrote:

> I'm not quite sure what questions to ask...
>
> I have a Debian box used by 10 or 12 people on a university campus; most
> of them are using it just as file-storage via Samba from their Windows/Macs
> boxes; a few are ssh'ing into it, etc, for other usages; some have web
> sites on it.
>
> For years their accounts have been maintained as local accounts on that
> Debian box, but as we're swapping out hardware, I'm also thinking it's time
> to swap out account management to let our campus-wide Active Directory
> provide their accounts instead of them (and me) having to maintain two
> separate sets of account credentials (three, if you include the samba
> file-sharing account on the old Debian setup).
>
> After considerable hair-pulling, I've managed to get the box to
> authenticate using their AD credentials, so that a user can simply ssh in
> without having an account on the box, using their AD credentials. But of
> course, their User IDs in AD are different than they were on the old Debian
> box, so their file permissions are different.
>
> Since it's just a dozen users or so, I can easily "id" their AD UID and
> "chown -R" their files in their home directory (which have been copied over
> manually from the old Debian box) to their AD UID.
>
> But that leaves several questions:
>
> 
>
> 3) Can I limit logins/file-sharing to just a subset of campus users (one
> department, not just anyone having a campus account)?
>
>
To answer my own question on this.

A detail I left out was that I set up my AD-authentication via "realmd", as
per this site:

http://www.alandmoore.com/blog/2015/05/06/joining-debian-8-to-active-directory/

To restrict logins to just certain users/groups, simply edit
/etc/sssd/sssd.conf, like as in this snippet:


#access_provider = ad
access_provider = simple
simple_allow_users = westk
simple_allow_groups = technology support admins,Mathematics


I could have left the "= ad" option and used more complex "allow" lines
(see docs for sssd.conf), but the "simple" option was easier. Anyone not
specified in an "allow" line is implicitly denied.

Don't forget you have to restart sssd after making any changes - systemctl
restart sssd

Note that there are other ways of accomplishing this task also (tinkering
with /etc/pam.d/sshd & /etc/pam.d/login & /etc/security/access.conf & etc),
but this route does what I need.



-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: Qs re: ActiveDirectory authentication & perms

[deloptes]

Kent West wrote:

> I'm not quite sure what questions to ask...
> 
> I have a Debian box used by 10 or 12 people on a university campus; most
> of them are using it just as file-storage via Samba from their
> Windows/Macs boxes; a few are ssh'ing into it, etc, for other usages; some
> have web sites on it.
> 
> For years their accounts have been maintained as local accounts on that
> Debian box, but as we're swapping out hardware, I'm also thinking it's
> time to swap out account management to let our campus-wide Active
> Directory provide their accounts instead of them (and me) having to
> maintain two separate sets of account credentials (three, if you include
> the samba file-sharing account on the old Debian setup).
> 
> After considerable hair-pulling, I've managed to get the box to
> authenticate using their AD credentials, so that a user can simply ssh in
> without having an account on the box, using their AD credentials. But of
> course, their User IDs in AD are different than they were on the old
> Debian box, so their file permissions are different.
> 
> Since it's just a dozen users or so, I can easily "id" their AD UID and
> "chown -R" their files in their home directory (which have been copied
> over manually from the old Debian box) to their AD UID.
> 
> But that leaves several questions:
> 
> 1) If I just "chown -R", that changes the ownership of all the files,
> regardless how the files may have been set-up on the old box. For example,
> I notice in at least one web directory for one user, the files were owned
> by www-data, with the group ownership set to the group name corresponding
> to the user's name on the old box. Changing that ownership from "www-data"
> to "joe_user" might break things. Is there a way to just chown the
> ownership of files already owned by the old username?
> 
> 2) The group that all the AD-authenticated users are in is "domain users".
> That means that any files formerly owned by suzy:suzy are now owned by
> suzy:"domain users", and if a file is set to 770 (or similar), any one of
> the people logging in can access any other person's files as a member of
> that group. Not good.
> 
> 2a) What's the best route for dealing with this group ownership issue? Can
> I remap the group for all AD-authenticated users to be their own username,
> like it was in the old Debian setup? Is that even a good idea?
> 
> 2b) I'm skittish of having spaces in group names (or files, etc), and
> would rather that "domain users" be something like "domain_users"; does
> the AD authentication process have some way of remapping that name to one
> without spaces? (Or this may be a moot question, depending on the answer
> to 2a above.)
> 
> 3) Can I limit logins/file-sharing to just a subset of campus users (one
> department, not just anyone having a campus account)?
> 
> 4) I haven't even begun to think about how to tie this into their samba
> (or is it "cifs" nowadays?) file shares. Any pointers dealing with that
> would be appreciated.
> 
> Thanks!
> 

I think your questions a properl addressed to the samba mailing list.

You can look into the samba configuration options - especially user/group
mapping. For the read/write permissions you can enforce specific or look
into acls. you can not remap group to username AFAIR - the name is not
important - important is the id behind the name. 2b again group mapping
question - but there is nothing wrong with spaces in this context - it
boils down to the gid again. 3) I think you can work with dedicated group
or you would have to maintain a list of allowed users. 4) look carefully in
the samba documentation there are actually a good guides for your scenario,
where almost all of this is explained. You are not discovering the steam
engine

https://www.howtoforge.com/samba_active_directory
https://help.ubuntu.com/lts/serverguide/samba-ad-integration.html
https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
https://wiki.samba.org/index.php/Samba,_Active_Directory_%26_LDAP

regards

Qs re: ActiveDirectory authentication & perms

[Kent West]

I'm not quite sure what questions to ask...

I have a Debian box used by 10 or 12 people on a university campus; most of
them are using it just as file-storage via Samba from their Windows/Macs
boxes; a few are ssh'ing into it, etc, for other usages; some have web
sites on it.

For years their accounts have been maintained as local accounts on that
Debian box, but as we're swapping out hardware, I'm also thinking it's time
to swap out account management to let our campus-wide Active Directory
provide their accounts instead of them (and me) having to maintain two
separate sets of account credentials (three, if you include the samba
file-sharing account on the old Debian setup).

After considerable hair-pulling, I've managed to get the box to
authenticate using their AD credentials, so that a user can simply ssh in
without having an account on the box, using their AD credentials. But of
course, their User IDs in AD are different than they were on the old Debian
box, so their file permissions are different.

Since it's just a dozen users or so, I can easily "id" their AD UID and
"chown -R" their files in their home directory (which have been copied over
manually from the old Debian box) to their AD UID.

But that leaves several questions:

1) If I just "chown -R", that changes the ownership of all the files,
regardless how the files may have been set-up on the old box. For example,
I notice in at least one web directory for one user, the files were owned
by www-data, with the group ownership set to the group name corresponding
to the user's name on the old box. Changing that ownership from "www-data"
to "joe_user" might break things. Is there a way to just chown the
ownership of files already owned by the old username?

2) The group that all the AD-authenticated users are in is "domain users".
That means that any files formerly owned by suzy:suzy are now owned by
suzy:"domain users", and if a file is set to 770 (or similar), any one of
the people logging in can access any other person's files as a member of
that group. Not good.

2a) What's the best route for dealing with this group ownership issue? Can
I remap the group for all AD-authenticated users to be their own username,
like it was in the old Debian setup? Is that even a good idea?

2b) I'm skittish of having spaces in group names (or files, etc), and would
rather that "domain users" be something like "domain_users"; does the AD
authentication process have some way of remapping that name to one without
spaces? (Or this may be a moot question, depending on the answer to 2a
above.)

3) Can I limit logins/file-sharing to just a subset of campus users (one
department, not just anyone having a campus account)?

4) I haven't even begun to think about how to tie this into their samba (or
is it "cifs" nowadays?) file shares. Any pointers dealing with that would
be appreciated.

Thanks!

-- 
Kent


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: permissions: can you force ACL to be effective over unix perms?

[Joel Rees]

On Sat, Jan 18, 2014 at 7:07 AM, Joel Rees  wrote:
> I have a little more time to work through what you originally wrote,
> sans certain assumptions I had when I originally responded.
>
> (And I didn't intend to post this off-list, so I'm posting it again, on list.
>
> Note -- if you aren't sure how to code some simple test routines using the C
> functions, let me know, and I'll post an example or two.)
>

You didn't ask, but I was feeling restless or something.  (My students
and family are complaining, even though it's taking more time to post
than it took to write.)


/* Quick and dirty check of file permission results.
// By Joel Rees, Copyright 2014, permission for reasonable use granted.
// (Stupid Berne Convention.)
*/

#include 
#include 

#define _GNU_SOURCE
#define __USE_GNU
#include 

static char const noStr[] = "Does not appear";
static char const yesStr[] = "Appears";



/* If euidaccess() is not available but eaccess is, enable this:
#define euidaccess eaccess
*/

/* If neither euidaccess() nor eaccess is available, comment this out:
*/
#define EFFECTIVE_AVAILABLE


int main( int argc, char * argv[] )
{
int argx;
if ( argc < 2 )
{ printf( "useage: %s  [ ...]\n", argv[ 0 ] );
}
for ( argx = 1; argx < argc; ++argx )
{ char * file = argv[ argx ];
printf( "permissions for <%s>:\n", file );
if ( access( file, F_OK ) < 0 )
{ perror( "\tIs it there?" );
}
else
{
puts( "\treal user:\n" );
if ( access( file, R_OK ) < 0 )
{ perror( "\tRead-ability:" );
}
else
{ puts( "\tAppears read-able." );
}
if ( access( file, W_OK ) < 0 )
{ perror( "\tWrite-ability:" );
}
else
{ puts( "\tAppears write-able." );
}
if ( access( file, X_OK ) < 0 )
{ perror( "\texecute-ability:" );
}
else
{ puts( "\tAppears executable-able." );
}
#if defined EFFECTIVE_AVAILABLE
if ( euidaccess( file, R_OK ) < 0 )
{ perror( "\tRead-ability:" );
}
else
{ puts( "\tAppears read-able." );
}
if ( euidaccess( file, W_OK ) < 0 )
{ perror( "\tWrite-ability:" );
}
else
{ puts( "\tAppears write-able." );
}
if ( euidaccess( file, X_OK ) < 0 )
{ perror( "\texecute-ability:" );
}
else
{ puts( "\tAppears executable-able." );
}
#endif /* defined EFFECTIVE_AVAILABLE */
}
}
return EXIT_SUCCESS;
}


Indent for readability, since the tabs didn't make it through gmail's
junk. Yes, I could've used Sylpheed, but that would have taken an
extra couple of minutes.

Save as ckaccess.c or whatever.

Compile with cc -Wall -o ckaccess ckaccess.c

Run with ./ckaccess as I'm sure you understand.

Open a second terminal session and su or sudo as necessary to make
files and directories in your test directory owned and grouped and
ACLed as needed to test.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caar43inzanauegxbnfixu_ilcbnubgxwn0di98p5mawoov6...@mail.gmail.com

Re: permissions: can you force ACL to be effective over unix perms?

[Joel Rees]

I have a little more time to work through what you originally wrote,
sans certain assumptions I had when I originally responded.

(And I didn't intend to post this off-list, so I'm posting it again, on list.

Note -- if you aren't sure how to code some simple test routines using the C
functions, let me know, and I'll post an example or two.)

On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg  wrote:
> running wheezy.
>
> I have a dir w/ unix perm = 750
> IE:
> root@wheezy:/home/chtest/home# ls -l
> drwxr-s---  3 rootchadm 4096 Jan  9 14:12 ftptest
>
> I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest
> this, unfortunately, changes unix perm to = 770
> IE:  V
> drwxrWs---+ 3 rootchadm 4096 Jan  9 14:12 ftptest

Note that the man page says

--
If  setfacl  is used on a file system which does not support ACLs, set‐
   facl operates on the file mode permission bits. If the ACL does not fit
   completely  in the permission bits, setfacl modifies the file mode per‐
   mission bits to reflect the ACL as closely as possible, writes an error
   message to standard error, and returns with an exit status greater than
   0.
--

Now that's not being perfectly explicit, but it points in a certain direction.

To be perfectly certain what is happening in debian, you'll need to
look at the code, and try some snippets with some of the routines that
come up when you do a

man -k permissions

and so forth. Of course, you'll need to do the experiments as a user
that you are sure won't have hidden keyloggers and such in the
background, since you'll be sudo-ing or su-ing to root for certain
parts of the tests.

And then you'll need to take your results to an appropriate dev list
and ask questions.

Frankly, I am still surprised that you express surprise at the results
and are looking for something different. (What you are looking for, I
can't tell.)

> I then re-removed unix g w perm: # chmod g-w ftptest
> IE:
> drwxr-s---+ 3 rootchadm 4096 Jan  9 14:12 ftptest
>
> This action causes unix perms to OVERRIDE acl perms - NOT what I want:
> IE:
> root@wheezy:/home/chtest/home# getfacl ftptest
> # file: ftptest
> # owner: root
> # group: chadm
> # flags: -s-
> user::rwx
> group::r-x
> group:chadm:rWx #effective:r-x
> mask::r-x 
> other::---

As near as I could tell then, and as near as I can tell now, it's
doing exactly what you told it to do.

> So - Is there a way to force ACL perms to dictate the effective rights??

Are you perhaps looking for tools that tell you more detail than you
are seeing? You might have a point, there.

> FWIW:
> it APPEARS to me that the acl access check algorithm will not allow this.
> however - since the entire acl sub-system was "meant to increase granularity
> of permissions" - shouldn't acl ALWAYS override unix perms? is this a bug in
> the ACL algorithm?

The only way I can parse this question is the reason I made the
assumptions that colored my original response. Anyway, if you don't
understand why
after using, for example

man 2 access

man 3 eaccess

(both of which come up when you man -k permssions), I'll see if I can
remember which library calls get you a good look at the binary
permissions.

Remember that "ls -l" and "stat" have a rather restricted format for
reporting permissions, a format that did not consider the possibility
that rwx permissions would need to be reportable for more than other,
and effective/real user/group.

> === end of my question; begin additional info ===
>
> because I KNOW someone will want to know why this is a problem - here's why,
> and I hope you're not sorry you asked !! :-)
>
> I'm using [openssh] internal-sftp to chroot users to their home dir.
> internal-sftp's chroot DEMANDS that all dir's leading to home MUST be
> root-owned, and NO g-w permissions !!

There is a reason for that. I remember reading about it when I
participated on the misc@openbsd list, but I don't remember the
specifics beyond that there are certain kinds of attacks that can be
closed off more effectively that way. Don't go ask on that list,
however, at least not without doing an awful lot more digging than you
have. The archives can be found on marc.info and other places if
general web searches don't turn it up for you.

> But my managers (members of group: chadm) must have full permissions in all
> sftp users' home dir's.

I see what you are trying to do and I still think it's a bad idea.

> So NEITHER my sftp user, NOR my managing group have write access to the home
> directory !?!?

Not unless you get the permissions set up in a way that th

Re: permissions: can you force ACL to be effective over unix perms?

[Gilles Mocellin]

Le 15/01/2014 00:21, Bob Goldberg a écrit :
On Tue, Jan 14, 2014 at 7:13 AM, Joel Rees > wrote:


Caveat. I don't have the patience to work with ACLs, mostly because I
can't see how they could really work without bringing a system to its
knees.


To be honest - ACL's were by far my first choice for solving my problem.
There is no doubt there's been misinterpretations; I'm sorry for that.

So let me drop back to square one, and explain what I want - at the 
highest level. SIMPLY, this:


I have 2 classes of users - SFTP users (customers), and SFTP managers 
(company users that manage customer data).


I want a highly secure and privacy safe SFTP server. But I also want 
it to appear to users as simple and easy as possible. All users will 
access SFTP only via an SFTP client.

so my wants are:
- sftp access only. (but not to exclude ssh access for linux users).
- sftp users chroot'ed to their home dir, without any added level's of 
directory's [beneath home].

- so users should have "w" access to their home.
- sftp managers should have "w" access to all sftp-users' home dir's.

what would be the best way to accomplish this?
I don't care how complex the setup/config is - as long as it's as 
easy, and idiot-proof for my users as possible.


TIA - Bob


Hello,

I have done something similar in the past with FTP (pure-ftpd).

The principle was just to have two level of directory, like this :

/srv/ftp/manager1/client1
/srv/ftp/manager1/client2
/srv/ftp/manager2/client3
/srv/ftp/manager2/client4
...

I was using virtual users, so the owner of all the hierarchy was the ftp 
user.

By having chrooted home at different level, you can have what you want.

manager1 : home dir /srv/ftp/manager1
client1 : home dir /srv/ftp/manager1/client1
client2 : home dir /srv/ftp/manager1/client2

manager1 can see files for both clients 1 and 2
client1 and client2 can only their own files

Re: permissions: can you force ACL to be effective over unix perms?

[Tom Furie]

On Tue, Jan 14, 2014 at 05:21:18PM -0600, Bob Goldberg wrote:

> I have 2 classes of users - SFTP users (customers), and SFTP managers
> (company users that manage customer data).
> 
> I want a highly secure and privacy safe SFTP server. But I also want it to
> appear to users as simple and easy as possible. All users will access SFTP
> only via an SFTP client.
> so my wants are:
> - sftp access only. (but not to exclude ssh access for linux users).
> - sftp users chroot'ed to their home dir, without any added level's of
> directory's [beneath home].
> - so users should have "w" access to their home.
> - sftp managers should have "w" access to all sftp-users' home dir's.
> 
> what would be the best way to accomplish this?
> I don't care how complex the setup/config is - as long as it's as easy, and
> idiot-proof for my users as possible.

The first thing that springs to mind is to have the home dirs owned by
the user, with rwx permission, and group of sftpmanager (for example),
with rwx permissions. Have your sftp managers (and only your sftp
managers) be members of group sftpmanager. You could add g+s permission
so newly created files will have group sftpmanager.

You mentioned that the ftp server you are using requires that all
directories leading to the home directories be owned by root with no
group write permissions. Does that apply even to the user's home itself?

Cheers,
Tom



signature.asc
Description: Digital signature

Re: permissions: can you force ACL to be effective over unix perms?

[Scott Ferguson]

On 15/01/14 10:00, Bob Goldberg wrote:
> On Mon, Jan 13, 2014 at 5:40 PM, Scott Ferguson
>  <mailto:scott.ferguson.debian.u...@gmail.com>> wrote:
> 
> I've followed the posts in this thread, dealing with the various
> tangents it's taken won't help you, probably the reason why it's
> received little attention.
> 
> 
> good point; noted, and TY.
>  
> 
> On 11/01/14 10:50, Bob Goldberg wrote:
> >
> > This action causes unix perms to OVERRIDE acl perms - NOT what I want
> 
> Then you'll have to find another way to achieve what you want.
> 
> *ACL should never override UNIX perms*. And they can't - if they did it
> 'would' be a bug.
> 
> 
> 
> 
> > shouldn't acl ALWAYS override unix perms?
> 
> 
> NO.  I'm sorry about your confusion, probably due to differences between
> the Windows system and UNIX. File attributes are not the same as UNIX
> permissions.
>  
> 
>  
> Scott;
> 
> you're right about my confusion; tho it doesn't stem from windows. I
> only used that ref. as an attempted comic comparison. (I actually
> learned *nix before windows existed).
> 
> Here's examples of where my confusion comes from:
> from: http://www.softpanorama.org/Commercial_linuxes/linux_acl.shtml
>>>
> /ACLs grant "higher-level" access rights that have priority over regular
> file permissions./


That's correct.  I won't get a chance till later tonight, but I need to
amend and retract my earlier emphatic statement. ACL does "override"
UNIX permissions, it can also "change" UNIX permissions - but they don't
conflict with the process/upsurp the order (root -> user -> group ->
world) resulting in anarchy. I know that doesn't make anything clearer -
probably because I'm a long way from expert on the subject  (I use ACL,
not design or define them).
In this instance we're talking about what I call ext2 ACL (I don't
remember the correct technical term)



I'm sorry I don't currently have time to give this thread the attention
it deserves. Thanks for the extra information about what you are wanting
to do as I was having trouble understanding, though not necessarily
through any failing on your part :)


Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d5cb2d.3040...@gmail.com

Re: permissions: can you force ACL to be effective over unix perms?

[Bob Goldberg]

On Tue, Jan 14, 2014 at 7:13 AM, Joel Rees  wrote:

> Caveat. I don't have the patience to work with ACLs, mostly because I
> can't see how they could really work without bringing a system to its
> knees.
>
>
To be honest - ACL's were by far my first choice for solving my problem.
There is no doubt there's been misinterpretations; I'm sorry for that.

So let me drop back to square one, and explain what I want - at the highest
level. SIMPLY, this:

I have 2 classes of users - SFTP users (customers), and SFTP managers
(company users that manage customer data).

I want a highly secure and privacy safe SFTP server. But I also want it to
appear to users as simple and easy as possible. All users will access SFTP
only via an SFTP client.
so my wants are:
- sftp access only. (but not to exclude ssh access for linux users).
- sftp users chroot'ed to their home dir, without any added level's of
directory's [beneath home].
- so users should have "w" access to their home.
- sftp managers should have "w" access to all sftp-users' home dir's.

what would be the best way to accomplish this?
I don't care how complex the setup/config is - as long as it's as easy, and
idiot-proof for my users as possible.

TIA - Bob

Re: permissions: can you force ACL to be effective over unix perms?

[Bob Goldberg]

On Mon, Jan 13, 2014 at 5:40 PM, Scott Ferguson <
scott.ferguson.debian.u...@gmail.com> wrote:

> I've followed the posts in this thread, dealing with the various
> tangents it's taken won't help you, probably the reason why it's
> received little attention.
>
>
good point; noted, and TY.


> On 11/01/14 10:50, Bob Goldberg wrote:
> >
> > This action causes unix perms to OVERRIDE acl perms - NOT what I want
>
> Then you'll have to find another way to achieve what you want.
>
> *ACL should never override UNIX perms*. And they can't - if they did it
> 'would' be a bug.
>
> 
>
>
> > shouldn't acl ALWAYS override unix perms?
>
>
> NO.  I'm sorry about your confusion, probably due to differences between
> the Windows system and UNIX. File attributes are not the same as UNIX
> permissions.
>


Scott;

you're right about my confusion; tho it doesn't stem from windows. I only
used that ref. as an attempted comic comparison. (I actually learned *nix
before windows existed).

Here's examples of where my confusion comes from:
from: http://www.softpanorama.org/Commercial_linuxes/linux_acl.shtml
>>
*ACLs grant "higher-level" access rights that have priority over regular
file permissions.*
<<

from: http://users.suse.com/~agruen/acl/linux-acls/online/
(under: Access Check Algorithm)
>>
*A process can be a member in more than one group, so more than one group
entry can match. If any of these matching group entries contain the
requested permissions, one that contains the requested permissions is
picked*
<<

I've read numerous articles which indicate ACL's should have priority over
normal unix-permissions.

my experiences, and information relayed in this thread contradict this.

whenever I have a problem - I always assume I'M doing something wrong.
These articles made me think my understanding was accurate, and therefore I
must not be communicating the problem correctly.

So - i'm happy to be wrong about something - that's how I learn. But if i'm
wrong here - then it appears there is a bug in the ACL implementation. (or
i've SERIOUSLY misinterpreted statements like those above).

If i'm wrong - i would really like to understand how i got here.

TIA - Bob

Re: permissions: can you force ACL to be effective over unix perms?

[Scott Ferguson]

On 15/01/14 00:13, Joel Rees wrote:
> Caveat. I don't have the patience to work with ACLs, mostly because I
> can't see how they could really work without bringing a system to its
> knees.
> 
> On Tue, Jan 14, 2014 at 8:04 AM, Bob Goldberg  wrote:
>> [...]
>>> I may be wrong here, but how could ACLs override the native
>>> permissions system randomly without opening tons of new opportunities
>>> for discovering vulnerabilities?
>>


> 
> (I still, for example, didn't understand why each login user should
> have his/its own associated group. Seemed like such a waste at the
> time. Did not understand that allocating a user/group pair is
> basically zero overhead over just allocating a user and sticking the
> user in some general group like "user" or "admin". Didn't understand
> that the advantage I thought I saw in using primary groups to collect
> users into such groups was a mirage. Rambling here.)

Private (primary) groups can be useful, I'm not sure what you mean by
mirage but they do have problems that ACL don't. Non-teamplayer e.g:-
chmod u-rwx,g-rx $someFile




I don't want to confuse or inflame the issue, as a result of Jon
Dowlands recent post in this thread (he's correct I've had to reconsider
what I posted. ACL's *can* modify/override UNIX permissions, though it's
not that simple. It is not random, anarchaic or more insecure than UNIX
permissions and groups.
I'm trying to put together an unambiguous explanation of the benefits of
ACL and retraction/clarification of my original post, and understand the
OP's problem. Just doesn't look like I'm going to finish it tonight/this
morning :(
 - I'm working through the OP's problem, but I still don't understand
some parts of it (I'll post more questions later) and agree with you
(Joel) that it doesn't "seem" to be the best approach. ACLs yes, the
rest of the approach I'm not sure I properly understand (and so far I
can't recreate Bob's problem.


Kind regards.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d543f0.9050...@gmail.com

Re: permissions: can you force ACL to be effective over unix perms?

[Joel Rees]

Caveat. I don't have the patience to work with ACLs, mostly because I
can't see how they could really work without bringing a system to its
knees.

On Tue, Jan 14, 2014 at 8:04 AM, Bob Goldberg  wrote:
> [...]
>> I may be wrong here, but how could ACLs override the native
>> permissions system randomly without opening tons of new opportunities
>> for discovering vulnerabilities?
>
>
> ACLs DO OVERRIDE the native permissions - that's THE WHOLE POINT OF HAVING
> THEM !! They DO NOT do so "randomly" - man setfacl, and see that, ACLs are
> VERY explicit in how they override system perms.

Actually, the man pages seem a little ambiguous to me, at precisely
the point where you want to find a bug and I want to see the system
utilities trying to provide ACL behavior without blowing holes in the
permissions wide enough to sail aircraft carriers through.

>> > is this a bug in
>> > the ACL algorithm?
>>
>> 8-o
>>
>
> not sure what's surprising here.

Never mind my surprise. It doesn't seem to help you.

> [...]
>> > I'm using [openssh] internal-sftp to chroot users to their home dir.
>> > internal-sftp's chroot DEMANDS that all dir's leading to home MUST be
>> > root-owned, and NO g-w permissions !!
>>
>> Do you understand why?
>
> do i understand WHY?
>
> maybe i don't fully understand why. though to be blunt - i don't entirely
> care why.

You should.

> [...]
>> Nevertheless, sudo offers a solution to that false problem that is far
>> more to the point. As long as you are careful not to take the easy
>> route and put all the managers in the (unix) sudo group (or wheel, or
>> root, etc.)
>
> sudo is NOT a solution.

Well, that cuts off my best offer at a solution to your problem.

> The whole point of ACLs is to provide a greater
> level of detail in addressing problems of permission-ing. Thus you don't
> have to give NON-admin users ANY access to admin level commands (ie: sudo).
>
> Further, my users don't know linux - they are simply using an sftp client to
> talk to this server. You can't "sudo" inside an sftp client.
>
>>
>> > So NEITHER my sftp user, NOR my managing group have write access to the
>> > home
>> > directory !?!?
>>
>> Are you really sure your managers want to do that?
>
>
> absolutely - I WANT THEM TO DO THAT!
> they are "sftp managers" - I WANT them to manage the contents of sftp-users'
> home dir's !
>
> Sorry for not making this point more clear.

Well, now I'm wondering if you are having problems making sure they
can access their own ftp home directories.

Initially, I thought you were trying to provide them access to other
users' home directories. My apologies if I misunderstood.

>> > (yes, i know i can create another sub-dir they can get at, but i don't
>> > want
>> > to - that's sloppy, and un-intuitive.)
>>
>> It's not sloppy, and it's only counter-intuitive to people who don't
>> understand security. (IMO, perhaps, but I have pretty strong reasons
>> for saying so.)
>
>
> it IS sloppy AND counter-intuitive TO linux noob users who don't understand
> why they can't write files directly to their own private "home" dir.

There was a time I thought it was sloppy. I didn't really understand
Unix permissions, and I wasn't familiar with making sudo work for me.

(I still, for example, didn't understand why each login user should
have his/its own associated group. Seemed like such a waste at the
time. Did not understand that allocating a user/group pair is
basically zero overhead over just allocating a user and sticking the
user in some general group like "user" or "admin". Didn't understand
that the advantage I thought I saw in using primary groups to collect
users into such groups was a mirage. Rambling here.)

> This entire exercise is one I undertook ONLY because of my concerns over
> security, and privacy, and my need and desire to provide not only a secure
> environment, but a FRIENDLY (intuitive) one also.

If you are having trouble giving them access to their own ftp home
directories, I'm thinking that's not something to solve with ACLs.

>> > This SEEMS like such a simple task. And it PAINS me to no end, that this
>> > task would be relatively easy to implement under windoze - but seems
>> > impossible to solve under linux !!???
>> > ...sup w/ dat !?!?
>> >
>>
>> *** MSWindows is a null argument. ***
>>
>
> at least we agree on that.  :-)

Do we?

>> (Do you understand why?)
>>

Re: permissions: can you force ACL to be effective over unix perms?

[Jonathan Dowland]

On Sat, Jan 11, 2014 at 09:41:19AM +0900, Joel Rees wrote:
> But I may be wrong.I don't use ACLs.

This normally sets alarm bells off in my head...
 
> I may be wrong here, but how could ACLs override the native
> permissions system randomly without opening tons of new opportunities
> for discovering vulnerabilities?

You do misunderstand what ACLs are for. Consider the classic UNIX
permission model and permitting the apache httpd daemon to read your
web documents. Unless the httpd daemon is owner or a member of the group
for your web documents, you must set o+r. With ACLS, you can
specifically allow the httpd user to read the file(s), but nobody else.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140114095604.gc20...@bryant.redmars.org

Re: permissions: can you force ACL to be effective over unix perms?

[Scott Ferguson]

I've followed the posts in this thread, dealing with the various
tangents it's taken won't help you, probably the reason why it's
received little attention.

On 11/01/14 10:50, Bob Goldberg wrote:
> running wheezy.
> 
> I have a dir w/ unix perm = 750
> IE:
> root@wheezy:/home/chtest/home# ls -l
> drwxr-s---  3 rootchadm 4096 Jan  9 14:12 ftptest
> 
> I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest
> this, unfortunately, changes unix perm to = 770
> IE:  V
> drwxrWs---+ 3 rootchadm 4096 Jan  9 14:12 ftptest
> 
> I then re-removed unix g w perm: # chmod g-w ftptest
> IE:
> drwxr-s---+ 3 rootchadm 4096 Jan  9 14:12 ftptest
> 
> This action causes unix perms to OVERRIDE acl perms - NOT what I want

Then you'll have to find another way to achieve what you want.

*ACL should never override UNIX perms*. And they can't - if they did it
'would' be a bug.




> shouldn't acl ALWAYS override unix perms?


NO.  I'm sorry about your confusion, probably due to differences between
the Windows system and UNIX. File attributes are not the same as UNIX
permissions.


Kind regards.




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d47986.80...@gmail.com

Re: permissions: can you force ACL to be effective over unix perms?

[Bob Goldberg]

Joel;

i'm confused by your comments, which i'll address individually; with
apologies in advance to the group for length, and content:

On Fri, Jan 10, 2014 at 6:41 PM, Joel Rees  wrote:

> On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg  wrote:
> >
> > So - Is there a way to force ACL perms to dictate the effective rights??
>
> It seems to me that I would want to understand the answer to this
> question before I try to use ACLs. Which means that, if I had to use
> ACLs for work, I would tell the boss I need a block of time to make a
> set of throw-away users and groups to test the results of things, to
> make sure that I understand the results I get.
>
> (Bosses who can't accept that kind of answer aren't fit to be bosses,
> but that observation only helps one to find a way to do the necessary
> job without taking the undeserved insults to heart. Or to tell the
> boss he can have his job if things get really, really bad.)
>
>
1) the REASON i'm asking the question above (which is explicitly about
ACLs) - IS BECAUSE I ALREADY HAVE SOME understanding of ACLs, but have a
question pertaining to specific functionality/behavior. I'm asking the
question because I'VE ALREADY GOT test users which i'm using as my test-lab
to attempt to answer my own questions.

2) I think you misunderstand my use of "managers" - these are NOT my bosses
- these are managers that work under me and on which, I WANT to impose
certain working behaviors.


> > FWIW:
> > it APPEARS to me that the acl access check algorithm will not allow this.
>
> I don't think you are understanding your results. (But I may be wrong.
> I don't use ACLs.)
>
>
i'm ALMOST speechless.
1) i think my question implicitly shows I DO UNDERSTAND my results. My
question relates directly to how ACLs are effecting my results. Further it
shows what I think the crux of my problem is - illustrating that I have
made an attempt to do considerable research on the problem.

2) "you don't use ACLs"  then why are you even responding, if you don't
understand the topic on which i'm querying 
You may question the sanity of my underlying premise, or goal - and that is
welcome - but CONSTRUCTIVE criticism is appreciated.


> > however - since the entire acl sub-system was "meant to increase
> granularity
> > of permissions" - shouldn't acl ALWAYS override unix perms?
>
> I may be wrong here, but how could ACLs override the native
> permissions system randomly without opening tons of new opportunities
> for discovering vulnerabilities?


ACLs DO OVERRIDE the native permissions - that's THE WHOLE POINT OF HAVING
THEM !! They DO NOT do so "randomly" - man setfacl, and see that, ACLs are
VERY explicit in how they override system perms.


> > is this a bug in
> > the ACL algorithm?
>
> 8-o
>
>
not sure what's surprising here.
I've laid out my understanding of ACLs, and by the stated intent of the ACL
sub-system (in the dpkg desc.), my results appear to demonstrate a
divergence in observed behavior, from my interpretation of the stated
intent.

The whole point of my email, is asking the community to either show me
where I'm wrong, or confirm that I may have found a bug; and/or to tell me
how to do this, assuming my understanding is correct.


> > === end of my question; begin additional info ===
> >
> > because I KNOW someone will want to know why this is a problem - here's
> why,
> > and I hope you're not sorry you asked !! :-)
> >
> > I'm using [openssh] internal-sftp to chroot users to their home dir.
> > internal-sftp's chroot DEMANDS that all dir's leading to home MUST be
> > root-owned, and NO g-w permissions !!
>
> Do you understand why?
>

do i understand WHY?

maybe i don't fully understand why. though to be blunt - i don't entirely
care why. My desire to work around this default behavior would seem to
already IMPLY i don't fully know why. I don't see my desires as being
detrimental to the security that openssh provides, because i'm enhancing
security with ACL - though i'm sure openssh doesn't know that. :)

PLUS: There's a difference between chroot'ing a user, which REQUIRES a
complete root environment; and internal-sftp's chroot'ing, which was added
to sftp to explicitly avoid the need for a complete root environment.

IF A USER IS INTERNAL-SFTP-chroot'ed TO HIS HOME DIR, NO, I don't see why
they shouldn't have write access to it.

if a managing group is not chroot'ed at all, NO, I do NOT see why that
group shouldn't be able to have write access [as a group] inside a
directory tree which chroot's other users whose group membership is
unrelat

Re: permissions: can you force ACL to be effective over unix perms?

[Joel Rees]

On Sat, Jan 11, 2014 at 8:50 AM, Bob Goldberg  wrote:
> running wheezy.
>
> I have a dir w/ unix perm = 750
> IE:
> root@wheezy:/home/chtest/home# ls -l
> drwxr-s---  3 rootchadm 4096 Jan  9 14:12 ftptest
>
> I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest
> this, unfortunately, changes unix perm to = 770
> IE:  V
> drwxrWs---+ 3 rootchadm 4096 Jan  9 14:12 ftptest
>
> I then re-removed unix g w perm: # chmod g-w ftptest
> IE:
> drwxr-s---+ 3 rootchadm 4096 Jan  9 14:12 ftptest
>
> This action causes unix perms to OVERRIDE acl perms - NOT what I want:
> IE:
> root@wheezy:/home/chtest/home# getfacl ftptest
> # file: ftptest
> # owner: root
> # group: chadm
> # flags: -s-
> user::rwx
> group::r-x
> group:chadm:rWx #effective:r-x
> mask::r-x     
> other::---
>
>
> So - Is there a way to force ACL perms to dictate the effective rights??

It seems to me that I would want to understand the answer to this
question before I try to use ACLs. Which means that, if I had to use
ACLs for work, I would tell the boss I need a block of time to make a
set of throw-away users and groups to test the results of things, to
make sure that I understand the results I get.

(Bosses who can't accept that kind of answer aren't fit to be bosses,
but that observation only helps one to find a way to do the necessary
job without taking the undeserved insults to heart. Or to tell the
boss he can have his job if things get really, really bad.)

> FWIW:
> it APPEARS to me that the acl access check algorithm will not allow this.

I don't think you are understanding your results. (But I may be wrong.
I don't use ACLs.)

> however - since the entire acl sub-system was "meant to increase granularity
> of permissions" - shouldn't acl ALWAYS override unix perms?

I may be wrong here, but how could ACLs override the native
permissions system randomly without opening tons of new opportunities
for discovering vulnerabilities? (Granularity is, itself, a problem,
as near as I can tell, although I know I'm going to get a lot of flack
from certain participants in this list for saying so.)

> is this a bug in
> the ACL algorithm?

8-o

> === end of my question; begin additional info ===
>
> because I KNOW someone will want to know why this is a problem - here's why,
> and I hope you're not sorry you asked !! :-)
>
> I'm using [openssh] internal-sftp to chroot users to their home dir.
> internal-sftp's chroot DEMANDS that all dir's leading to home MUST be
> root-owned, and NO g-w permissions !!

Do you understand why?

> But my managers (members of group: chadm) must have full permissions in all
> sftp users' home dir's.

Managers sometimes make really unreasonable demands. And sometimes
they make impossible demands.

Nevertheless, sudo offers a solution to that false problem that is far
more to the point. As long as you are careful not to take the easy
route and put all the managers in the (unix) sudo group (or wheel, or
root, etc.)

> So NEITHER my sftp user, NOR my managing group have write access to the home
> directory !?!?

Are you really sure your managers want to do that?

> (yes, i know i can create another sub-dir they can get at, but i don't want
> to - that's sloppy, and un-intuitive.)

It's not sloppy, and it's only counter-intuitive to people who don't
understand security. (IMO, perhaps, but I have pretty strong reasons
for saying so.)

> This SEEMS like such a simple task. And it PAINS me to no end, that this
> task would be relatively easy to implement under windoze - but seems
> impossible to solve under linux !!???
> ...sup w/ dat !?!?
>
> TIA - Bob
>

*** MSWindows is a null argument. ***

(Do you understand why?)

I strongly recommend the shared directory approach for sharing, and if
your managers really insist on having access to things they shouldn't
have, set sudo up to give them that access (and nothing else), and use
some appropriate aliases and indirecting scripts so they can sense
their importance without understanding that they are just using sudo
to override their own systems' security. ("Oh, cool! I have this
little tool called "eavesdrop" that allows me to peek into all the
users' home directories!" Or whatever.)

Otherwise, take the time and go back and make sure that you understand
the results of your initial experiments, even if it means "service
overtime". (Or if the boss has been getting too much service overtime
from you,  )

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAr43iNnsHzs8esutyjYf1Ma82=-c17+9bn4r6b_syapotu...@mail.gmail.com

permissions: can you force ACL to be effective over unix perms?

[Bob Goldberg]

running wheezy.

I have a dir w/ unix perm = 750
IE:
root@wheezy:/home/chtest/home# ls -l
drwxr-s---  3 rootchadm 4096 Jan  9 14:12 ftptest

I added an acl g perm using: # setfacl -m g:chadm:rwx ftptest
this, unfortunately, changes unix perm to = 770
IE:  V
drwxrWs---+ 3 rootchadm 4096 Jan  9 14:12 ftptest

I then re-removed unix g w perm: # chmod g-w ftptest
IE:
drwxr-s---+ 3 rootchadm 4096 Jan  9 14:12 ftptest

This action causes unix perms to OVERRIDE acl perms - NOT what I want:
IE:
root@wheezy:/home/chtest/home# getfacl ftptest
# file: ftptest
# owner: root
# group: chadm
# flags: -s-
user::rwx
group::r-x
group:chadm:rWx #effective:r-x
mask::r-x 
other::---


So - Is there a way to force ACL perms to dictate the effective rights??

FWIW:
it APPEARS to me that the acl access check algorithm will not allow this.
however - since the entire acl sub-system was "meant to increase
granularity of permissions" - shouldn't acl ALWAYS override unix perms? is
this a bug in the ACL algorithm?

=== end of my question; begin additional info ===

because I KNOW someone will want to know why this is a problem - here's
why, and I hope you're not sorry you asked !! :-)

I'm using [openssh] internal-sftp to chroot users to their home dir.
internal-sftp's chroot DEMANDS that all dir's leading to home MUST be
root-owned, and NO g-w permissions !!

But my managers (members of group: chadm) must have full permissions in all
sftp users' home dir's.

So NEITHER my sftp user, NOR my managing group have write access to the
home directory !?!?
(yes, i know i can create another sub-dir they can get at, but i don't want
to - that's sloppy, and un-intuitive.)

This SEEMS like such a simple task. And it PAINS me to no end, that this
task would be relatively easy to implement under windoze - but seems
impossible to solve under linux !!???
...sup w/ dat !?!?

TIA - Bob

Re: "reset" perms and ownerships

[Andrei POPESCU]

On Mi, 23 oct 13, 20:57:30, Bob Proulx wrote:
> 
>  The dlocate command is a
> fast indexed 'dpkg -S' command.  You will likely need to 'apt-get
> install dlocate' to have it but it is so much faster than 'dpkg -S'
> that it is very useful to install.

Cool!

Thanks for the tip,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: "reset" perms and ownerships

[Bob Proulx]

Mário Barbosa wrote:
> sudo chown -R : /
> ... and then came back to me for help.

Oh my goodness!

> I'm a sysadmin on the RH/CentOS camp, and my confort level with
> apt-* and dpkg* is extremely low.
> 
> Is there anything like "rpm -V" on the debian toolset? I'm trying to
> avoid "punishing him" (further) with reinstall...

Because this is ownership and permissions I don't think there is a
completely trivial solution.  There is 'debsums'.  But that won't be
sufficient since it is looking specifically at file content.  And I
saw the other suggestions.  I would NOT have done a dpkg -Gi on the
archives directory.

(I may have done an apt-get install --reinstall on a list of packages
that were installed on the system, a list from dpkg -l | awk
'{print$2}'.  But that would blow up the apt extended_states file and
marked everything as manually installed.  See 'man apt-mark'.  Would
have saved it off before and restored it aftward.
  cp /var/lib/apt/extended_states /root/
  apt-get install --reinstall $(dpkg -l | awk '{print$2}')
  cp /root/extended_states /var/lib/apt/
You get the idea.
)

Here is what I would have done.  If I were wanting to "save" the
system rather than install again.

I assume the system is very unhappy.  I would mount the disk on a
different good system and save it from there.  Otherwise I would work
across two systems.  Reset the values from the known good to the
mangled.

I would generate a list of files on the mangled system.  Avoid all of
the tmpfs and proc filesystems.  Then I would do the same on the host
system or a different known good similar system used as a reference.
Then I would find the common set of files between the two.  I would
see what ownership and permissions lived on the good system for those
files and generate a script to set the mangled system to the same.  I
would just do it on the fly on the command line using grep and sort
and awk and comm and those types of things.

Of course that is where the work is done but I would scramble around
and convert 'stat' output into commands to reproduce the ownership and
permissions.

  xargs stat --printf "chown %U %n\n" < filelist > cmdfile

That will be broken for any files with whitespace in it but the system
doesn't have any of those.  Inspect for whitespace and scrape those
out and handle manually.  Then do the same for permissions.  And so
forth.  Craft the script to restore the ownership and permissions.
Then run the script!

Be careful not to break the host system with an absolute path to the
target system!  (I did that once so am speaking from experience.
D'oh!)  That should get 90% of everything back into good shape again.
Use a good reference system to determine what ownership and permission
the mangled system should have.

That will still leave some files that are installed on the mangled
system that do not have known good info from the reference system.
Take that list and run it through 'dlocate'.  The dlocate command is a
fast indexed 'dpkg -S' command.  You will likely need to 'apt-get
install dlocate' to have it but it is so much faster than 'dpkg -S'
that it is very useful to install.

  xargs dlocate < filelist | awk '{print$1}' | sort -u >pkglist

That will produce a packge list of the files that you don't have
information for.  I would possibly install those on a test system just
to get the right ownerships and permissons for them.  I would install
in a VM and then throw the VM away afterward.  I create a lot of
throwaway VMs for testing things like this so for me that is natural.
But a real machine would be fine too.

Or probably for 99% of those files you would know immediately what
needs to be done by visual inspection and would just do the right
chown and chmod commands to fix it.  But at least by that time it
would be a much smaller list.  Then I would probably have done the
apt-get install --reinstall of every installed package as discussed
above just to be as safe as possible.

I know this probably isn't helpful now at this late date.  But that
type of thing is the way I would have attacked the problem.  There
isn't any canonically right answer.  At some point everyone just uses
their best judgement and muddles through these problems as best as
they can.

Bob


signature.asc
Description: Digital signature

Re: "reset" perms and ownerships

[berenger . morel]

Le 23.10.2013 16:24, Mário Barbosa a écrit :

On 10/23/2013 02:48 PM, berenger.mo...@neutralite.org wrote:


I already did something along the lines of...

cd /var/cache/apt/archives
ls -1 *.deb | xargs sudo dpkg -Gi


But this will install everything you installed if you never cleaned 
that

dir... you may find useful this command in the future:
$ aptitude search '~i'

The ~i means all installed packages. The generated list will include 
all
automatically installed packages so it's not perfect for your needs, 
but
I do not remember the exact syntax to exclude them. Aptitude's 
manual

should help here.


Thank you for this tip. Added it to my "toolbox" (my own private
command cheat sheets).


[...]


Upon further investigation, here's what was done:

sudo chown -R : /


wow... he really did that on /. You could add to the lesson to never 
use

recursive changes on root directory I guess...



In his defense, his only mistake was running a post-receive hook out
of its context (different current dir, different user). What is
written in that hook/script is my responsibility.

Rhetoric:
* Should he have done it? No.
* Should I have enforced proper working dir? Probably yes.

He is not a sysadmin, so maybe I should have anticipated some of
these "wildcard" type of actions...


Checking all external data is always a good idea in programming. Users 
(humans or external softwares) can do really strange things sometimes.



You could try to not reinstall the whole system with installer, but
simply use aptitude (with the ncurse interface) to purge (and not
remove, so that configuration files are removed and reinstalled) all
packages. Then, installing them back, if you know what you need. 
Given
that you still have the files in /var/cache/apt/archives it should 
not
involve any downloading, and you will skip the installer's 
questions.
Between the purge and reinstalling, you could probably change back 
every

ownership and perms to root in / (except /home of course) and remove
users and groups which could have been installed by packages.

It is simply a solution which might be faster than reinstalling. Or 
not,

it depends on what you have installed so far.


The idea of purging config files "scares" me quite a bit. Are edited
files saved somewhere (like rpm does with the ".rpmsave" extensions)?
Maybe then I'm trading one type of problem for another (the new one
being "validating that every config is set as needed")...


No, they are not saved, you have to do that manually (but it only 
affects those in /etc, not userland files).

Exactly as if you were trying to reinstall from scratch, in fact.


Berenger, thank you for your help. Please, waste no more of your time
on this.


Not a real loss of time.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ce16e902ab687b3d36743e111a349...@neutralite.org

Re: "reset" perms and ownerships

[Mário Barbosa]

On 10/23/2013 02:48 PM, berenger.mo...@neutralite.org wrote:


I already did something along the lines of...

cd /var/cache/apt/archives
ls -1 *.deb | xargs sudo dpkg -Gi


But this will install everything you installed if you never cleaned that
dir... you may find useful this command in the future:
$ aptitude search '~i'

The ~i means all installed packages. The generated list will include all
automatically installed packages so it's not perfect for your needs, but
I do not remember the exact syntax to exclude them. Aptitude's manual
should help here.


Thank you for this tip. Added it to my "toolbox" (my own private command 
cheat sheets).



[...]


Upon further investigation, here's what was done:

sudo chown -R : /


wow... he really did that on /. You could add to the lesson to never use
recursive changes on root directory I guess...



In his defense, his only mistake was running a post-receive hook out of 
its context (different current dir, different user). What is written in 
that hook/script is my responsibility.


Rhetoric:
* Should he have done it? No.
* Should I have enforced proper working dir? Probably yes.

He is not a sysadmin, so maybe I should have anticipated some of these 
"wildcard" type of actions...




You could try to not reinstall the whole system with installer, but
simply use aptitude (with the ncurse interface) to purge (and not
remove, so that configuration files are removed and reinstalled) all
packages. Then, installing them back, if you know what you need. Given
that you still have the files in /var/cache/apt/archives it should not
involve any downloading, and you will skip the installer's questions.
Between the purge and reinstalling, you could probably change back every
ownership and perms to root in / (except /home of course) and remove
users and groups which could have been installed by packages.

It is simply a solution which might be faster than reinstalling. Or not,
it depends on what you have installed so far.


The idea of purging config files "scares" me quite a bit. Are edited 
files saved somewhere (like rpm does with the ".rpmsave" extensions)? 
Maybe then I'm trading one type of problem for another (the new one 
being "validating that every config is set as needed")...



Berenger, thank you for your help. Please, waste no more of your time on 
this.


Best,
Mário Barbosa


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/5267dc2a.9070...@gmail.com

Re: "reset" perms and ownerships

[berenger . morel]

Le 23.10.2013 15:29, Mário Barbosa a écrit :

Hi,

On 10/23/2013 01:33 PM, berenger.mo...@neutralite.org wrote:
[...]

Hopefully he'll remember that using super user powers have to be 
made

with care :)


He will. :)


Is there anything like "rpm -V" on the debian toolset? I'm trying 
to

avoid "punishing him" (further) with reinstall...


It does not do any control (which is the role of rpm -V if I 
understood
correctly the man), but apt-get --reinstall might help. But if he 
did
the changes on /etc, it won't work, because configuration files 
won't be

modified ( it removes and installs, not purge and installs ).


I already did something along the lines of...

cd /var/cache/apt/archives
ls -1 *.deb | xargs sudo dpkg -Gi


But this will install everything you installed if you never cleaned 
that dir... you may find useful this command in the future:

$ aptitude search '~i'

The ~i means all installed packages. The generated list will include 
all automatically installed packages so it's not perfect for your needs, 
but I do not remember the exact syntax to exclude them. Aptitude's 
manual should help here.



(after manually fixing ownerships on sudo binaries, working dir's,
and config/data files)

... which apparently solves some of the problems, but is far from
fixing everything (ownerships of /etc and /var being just two
examples).

I think you might have solutions, but what has been changed, 
exactly?
Software binaries in /usr? Configuration files in /etc? Other stuff 
in

/var?


Upon further investigation, here's what was done:

sudo chown -R : /


wow... he really did that on /. You could add to the lesson to never 
use recursive changes on root directory I guess...


Maybe simply changing back the perms and ownerships might be 
simpler, too.


Thought about it, but I have no reference to mimic (meaning: I have
no definite list of previous user and group ownerships to
refer/compare to).


Guess I'll bite the bullet and reinstall the machine (with the added
advantage of solving other - unrelated - problems).


You could try to not reinstall the whole system with installer, but 
simply use aptitude (with the ncurse interface) to purge (and not 
remove, so that configuration files are removed and reinstalled) all 
packages. Then, installing them back, if you know what you need. Given 
that you still have the files in /var/cache/apt/archives it should not 
involve any downloading, and you will skip the installer's questions.
Between the purge and reinstalling, you could probably change back 
every ownership and perms to root in / (except /home of course) and 
remove users and groups which could have been installed by packages.


It is simply a solution which might be faster than reinstalling. Or 
not, it depends on what you have installed so far.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/b6c307dee7091fe054504fad170dd...@neutralite.org

Re: "reset" perms and ownerships

[Mário Barbosa]

Hi,

On 10/23/2013 01:33 PM, berenger.mo...@neutralite.org wrote:
[...]


Hopefully he'll remember that using super user powers have to be made
with care :)


He will. :)



Is there anything like "rpm -V" on the debian toolset? I'm trying to
avoid "punishing him" (further) with reinstall...


It does not do any control (which is the role of rpm -V if I understood
correctly the man), but apt-get --reinstall might help. But if he did
the changes on /etc, it won't work, because configuration files won't be
modified ( it removes and installs, not purge and installs ).


I already did something along the lines of...

cd /var/cache/apt/archives
ls -1 *.deb | xargs sudo dpkg -Gi

(after manually fixing ownerships on sudo binaries, working dir's, and 
config/data files)


... which apparently solves some of the problems, but is far from fixing 
everything (ownerships of /etc and /var being just two examples).




I think you might have solutions, but what has been changed, exactly?
Software binaries in /usr? Configuration files in /etc? Other stuff in
/var?


Upon further investigation, here's what was done:

sudo chown -R : /



Maybe simply changing back the perms and ownerships might be simpler, too.


Thought about it, but I have no reference to mimic (meaning: I have no 
definite list of previous user and group ownerships to refer/compare to).



Guess I'll bite the bullet and reinstall the machine (with the added 
advantage of solving other - unrelated - problems).



Thank you for your help,
Mário Barbosa


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/5267cf3e.9050...@gmail.com

Re: "reset" perms and ownerships

[berenger . morel]

Le 23.10.2013 14:13, Mário Barbosa a écrit :

Hi,

( this is most likely a RTFM question, please just point me to the 
right FM)


One inexperienced colleague just something along the likes of...

 "sudo chown : / ; sudo chmod  /"

(it's actually a little more elaborate than that, but you get the 
picture)


... and then came back to me for help.


Hopefully he'll remember that using super user powers have to be made 
with care :)



I'm a sysadmin on the RH/CentOS camp, and my confort level with apt-*
and dpkg* is extremely low.

Is there anything like "rpm -V" on the debian toolset? I'm trying to
avoid "punishing him" (further) with reinstall...


It does not do any control (which is the role of rpm -V if I understood 
correctly the man), but apt-get --reinstall might help. But if he did 
the changes on /etc, it won't work, because configuration files won't be 
modified ( it removes and installs, not purge and installs ).


I think you might have solutions, but what has been changed, exactly? 
Software binaries in /usr? Configuration files in /etc? Other stuff in 
/var?


Maybe simply changing back the perms and ownerships might be simpler, 
too.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/eb6a41a64711a36653a17e3786880...@neutralite.org

"reset" perms and ownerships

[Mário Barbosa]

Hi,

( this is most likely a RTFM question, please just point me to the right FM)

One inexperienced colleague just something along the likes of...

 "sudo chown : / ; sudo chmod  /"

(it's actually a little more elaborate than that, but you get the picture)

... and then came back to me for help.

I'm a sysadmin on the RH/CentOS camp, and my confort level with apt-* 
and dpkg* is extremely low.


Is there anything like "rpm -V" on the debian toolset? I'm trying to 
avoid "punishing him" (further) with reinstall...


Thanks in advance,
Mário Barbosa


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/5267bd5a.70...@gmail.com

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Kelly Clowers]

On Tue, May 15, 2012 at 7:32 PM, Martin McCormick
 wrote:


>        After purging and restoring pulseaudio and all the
> applications that needed it, I started looking at .pulse in my
> home directory as I didn't put it there to begin with. I
> expected to find it empty and there was the cause of all the
> trouble. A listing of that directory is:
>
> 43ec7b6e5a01418f517b36351654-card-database.tdb
> 43ec7b6e5a01418f517b36351654-default-sink
> 43ec7b6e5a01418f517b36351654-default-source
> 43ec7b6e5a01418f517b36351654-device-volumes.tdb
> 43ec7b6e5a01418f517b36351654-runtime
> 43ec7b6e5a01418f517b36351654-stream-volumes.tdb
>
>        When all files are present, the trouble happens. If I
> remove them, it works. Pulseaudio soon rebuilds all of them and
> the trouble returns. I have quickly read the man page for
> pulseaudio and for the pulse-daemon.conf file and there is not a
> word about these files and how to manage them but I think that
> pulseaudio is confused about this sound card and is putting the
> wrong tdb file in place.
>
>        That is why I say I am closer but I don't have it fixed
> yet as the rebuild occurs within seconds after removing
> .pulse/*. If you remove .pulse, pulseaudio kindly puts it back
> also and then repopulates it. I want to disable as little as
> possible as probably only one of the files is the villain.
>
> Thanks very much for your help as it made me look more closely
> at what was there.

I have been having problems with PA in experimental/unstable.
They don't seem to be exactly the same problems, but perhaps
there is some connection.

Have you looked in detail at the PA config with "pactl list"? In
my case, I needed to add the card and the sink with something
like
"pactl load-module module-alsa-card" and
"pactl load-module module-alsa-sink"
(not at home, so I don't have the exact commands).

In general pactl was a very helpful utility that I had not noticed
until the fine folks at #pulseaudio on freenode pointed it out to
me.


Cheers,
Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFoWM=-gAoGtCZmJqqNOnJLgFdkHC6PX7Va7cu21jHAc+sA
@mail.gmail.com

.pulse causes no sound (was ... Re: wheezy Audio Works for Root, Dies for User and it's not Perms.)

[Chris Bannister]

On Tue, May 15, 2012 at 09:32:09PM -0500, Martin McCormick wrote:
>   After purging and restoring pulseaudio and all the
> applications that needed it, I started looking at .pulse in my
> home directory as I didn't put it there to begin with. I

Creating another user would have produced the same result.

> expected to find it empty and there was the cause of all the
> trouble. A listing of that directory is:
> 
> 43ec7b6e5a01418f517b36351654-card-database.tdb
> 43ec7b6e5a01418f517b36351654-default-sink
> 43ec7b6e5a01418f517b36351654-default-source
> 43ec7b6e5a01418f517b36351654-device-volumes.tdb
> 43ec7b6e5a01418f517b36351654-runtime
> 43ec7b6e5a01418f517b36351654-stream-volumes.tdb
> 
>   When all files are present, the trouble happens. If I
> remove them, it works. Pulseaudio soon rebuilds all of them and
> the trouble returns. I have quickly read the man page for
> pulseaudio and for the pulse-daemon.conf file and there is not a
> word about these files and how to manage them but I think that
> pulseaudio is confused about this sound card and is putting the
> wrong tdb file in place.

Good deduction Watson!, but can you prove it? :)

Can you live without pulse?

You could do as Cameleon suggested, and look in that alsa-pulse.conf
file, but I'm guessing it is generated on package install AND/OR is used to
help generate the .pulse files in your home directory.

File a bug with reportbug and attach the faulty alsa-pulse.conf file.

-- 
"Religion is excellent stuff for keeping common people quiet."
   -- Napoleon Bonaparte


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120516035859.GA5090@tal

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Martin McCormick]

Getting much closer!

Chris Bannister writes:
> Was the netinst ISO a daily-build? There was some talk of one of the
> daily-build ISO's being faulty, I don't know in which way the fault
> would manifest itself though, and I don't know which one.

It was Daily Build 6 or 7 but read on.

> Have you done an update/upgrade cycle since installing Wheezy?

Numerous times.

> If you are interested in FINDING the cause of the fault then I'd suggest
> not to do that just yet, but if you just want the fault fixed then an
> update/upgrade cycle may fix it BUT you won't know what the culprit was.


There was no change.

> Might help. I'd try another user first though. Also another technique is
> to cut/paste errors into google (easier + quicker)
> 
> I think that was a alsa-pulse.conf file where it mentioned errors?
> 
> You could temporarily purge pulse to see if that helps. Do a purge, not
> just a remove, cause it looks like some sort of configuration file
> causing the problem. Also remember, a purge does NOT remove any files in
> your home directory, so if there are any pulse files in there they will
> not be removed. (Note: Trying another user FIRST will help here.)

This was a great help. Here is what I found.

After purging and restoring pulseaudio and all the
applications that needed it, I started looking at .pulse in my
home directory as I didn't put it there to begin with. I
expected to find it empty and there was the cause of all the
trouble. A listing of that directory is:

43ec7b6e5a01418f517b36351654-card-database.tdb
43ec7b6e5a01418f517b36351654-default-sink
43ec7b6e5a01418f517b36351654-default-source
43ec7b6e5a01418f517b36351654-device-volumes.tdb
43ec7b6e5a01418f517b36351654-runtime
43ec7b6e5a01418f517b36351654-stream-volumes.tdb

When all files are present, the trouble happens. If I
remove them, it works. Pulseaudio soon rebuilds all of them and
the trouble returns. I have quickly read the man page for
pulseaudio and for the pulse-daemon.conf file and there is not a
word about these files and how to manage them but I think that
pulseaudio is confused about this sound card and is putting the
wrong tdb file in place.

That is why I say I am closer but I don't have it fixed
yet as the rebuild occurs within seconds after removing
.pulse/*. If you remove .pulse, pulseaudio kindly puts it back
also and then repopulates it. I want to disable as little as
possible as probably only one of the files is the villain.

Thanks very much for your help as it made me look more closely
at what was there.

Martin


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205160232.q4g2w9hr083...@x.it.okstate.edu

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Camaleón]

On Tue, 15 May 2012 06:27:43 -0500, Martin McCormick wrote:

> The system in question has one user account and that account is in the
> audio group. The errors do not look like the traditional 
> permission-related problems. Here is a sample of what happens. It has
> never worked once since the wheezy installation.

(...)

> conf.c:3406:(config_file_open) /usr/share/alsa/pulse-alsa.conf may be old or 
> corrupted: consider to remove or fix it 

(...)

And have you ever considered in doing what the message suggests? :-)

(well, don't remove the file but rename or move it to another place)

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jotsul$tg8$9...@dough.gmane.org

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Chris Bannister]

On Tue, May 15, 2012 at 08:54:09AM -0500, Martin McCormick wrote:
> I used the wheezy netinst ISO image to run the install and my
> home directory was created from the installation media and the
> problem was immediately noticed. Since then, I copied my home
> directory from a working system to this new one so as to have
> sound files and other types of files to play with but there are
> no sound configuration files.

Was the netinst ISO a daily-build? There was some talk of one of the
daily-build ISO's being faulty, I don't know in which way the fault
would manifest itself though, and I don't know which one.

Have you done an update/upgrade cycle since installing Wheezy?
If you are interested in FINDING the cause of the fault then I'd suggest
not to do that just yet, but if you just want the fault fixed then an
update/upgrade cycle may fix it BUT you won't know what the culprit was.

>   When I am home from work, I will check permissions on
> /usr/share and make sure that a user can read the files and post

I wouldn't bother. I think you'd be "barking up the wrong tree".

> the trace leading up to the first error on the bad trace and the
> coresponding part of the good trace.

Might help. I'd try another user first though. Also another technique is
to cut/paste errors into google (easier + quicker) 

I think that was a alsa-pulse.conf file where it mentioned errors?

You could temporarily purge pulse to see if that helps. Do a purge, not
just a remove, cause it looks like some sort of configuration file
causing the problem. Also remember, a purge does NOT remove any files in
your home directory, so if there are any pulse files in there they will
not be removed. (Note: Trying another user FIRST will help here.)

Good Luck!

-- 
"Religion is excellent stuff for keeping common people quiet."
   -- Napoleon Bonaparte


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515152137.GA26048@tal

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Martin McCormick]

Chris Bannister writes:
> Does it work for another user? Temporarily create one to find out.

Good suggestion.

> Dont like the look of "/usr/share/alsa/pulse-alsa.conf may be old or
> corrupted: consider to remove or fix it"

That looks bad all right until root runs the same command,
accesses the same file and works perfectly.

> Is this a stock, OOTB, setup, or have you altered any personal config
> files?

I used the wheezy netinst ISO image to run the install and my
home directory was created from the installation media and the
problem was immediately noticed. Since then, I copied my home
directory from a working system to this new one so as to have
sound files and other types of files to play with but there are
no sound configuration files.

> >   I ran strace -e trace=open,close,read,write and the good
> > trace wasn't all that much different from the bad trace.
> 
> So there were differences?

Yes. The errors are only in the bad trace and there seems to be
a mention of a machine ID or something similar just before the
first error messages are generated.

I compared the output of the good trace with that of the bad one
and the only differences before the errors start are the session
cookies which one would expect to differ and path names for
local pulse configuration files which do not exist either in
root's directory or mine.

From previous testing, I can report that amixer as run
from root goes right to the sound card and all the settings are
there and sensable. From my account, amixer provokes a spew of
errors that look like the same ones aplay causes to occur.

When I am home from work, I will check permissions on
/usr/share and make sure that a user can read the files and post
the trace leading up to the first error on the bad trace and the
coresponding part of the good trace.

Thank you.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205151354.q4fds91h080...@x.it.okstate.edu

Re: wheezy Audio Works for Root, Dies for User and it's not Perms.

[Chris Bannister]

On Tue, May 15, 2012 at 06:27:43AM -0500, Martin McCormick wrote:
> Script started on Tue 15 May 2012 05:29:48 AM CDT
> martin@m:~$ aplay -l
>  List of PLAYBACK Hardware Devices 
> ALSA lib conf.c:1220:(parse_def) show is not a compound
> ALSA lib conf.c:1686:(snd_config_load1) _toplevel_:24:26:Unexpected char
> ALSA lib conf.c:3406:(config_file_open) /usr/share/alsa/pulse-alsa.conf may 
> be old or corrupted: consider to remove or fix it
> card 0: ICH5 [Intel ICH5], device 0: Intel ICH [Intel ICH5]
>   Subdevices: 0/1
>   Subdevice #0: subdevice #0
> card 0: ICH5 [Intel ICH5], device 4: Intel ICH - IEC958 [Intel ICH5 - IEC958]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> martin@m:~$ 
> martin@m:~$ exit

Does it work for another user? Temporarily create one to find out.
Dont like the look of "/usr/share/alsa/pulse-alsa.conf may be old or
corrupted: consider to remove or fix it" 

Is this a stock, OOTB, setup, or have you altered any personal config
files?  

>   I ran strace -e trace=open,close,read,write and the good
> trace wasn't all that much different from the bad trace.

So there were differences?

-- 
"Religion is excellent stuff for keeping common people quiet."
   -- Napoleon Bonaparte


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515124008.GA23735@tal

wheezy Audio Works for Root, Dies for User and it's not Perms.

[Martin McCormick]

The system in question has one user account and that
account is in the audio group. The errors do not look like the
traditional  permission-related problems. Here is a sample of
what happens. It has never worked once since the wheezy
installation.

Script started on Tue 15 May 2012 05:29:48 AM CDT
martin@m:~$ aplay -l
 List of PLAYBACK Hardware Devices 
ALSA lib conf.c:1220:(parse_def) show is not a compound
ALSA lib conf.c:1686:(snd_config_load1) _toplevel_:24:26:Unexpected char
ALSA lib conf.c:3406:(config_file_open) /usr/share/alsa/pulse-alsa.conf may be 
old or corrupted: consider to remove or fix it
card 0: ICH5 [Intel ICH5], device 0: Intel ICH [Intel ICH5]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: ICH5 [Intel ICH5], device 4: Intel ICH - IEC958 [Intel ICH5 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
martin@m:~$ 
martin@m:~$ exit

The card lookup was the correct information.

Script started on Tue 15 May 2012 05:31:24 AM CDT
root@m:~# aplay -l
 List of PLAYBACK Hardware Devices 
card 0: ICH5 [Intel ICH5], device 0: Intel ICH [Intel ICH5]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: ICH5 [Intel ICH5], device 4: Intel ICH - IEC958 [Intel ICH5 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
root@m:~# exit

Not only does it correctly find the card, but sound works.
mplayer works properly, playing sound files and internet radio.

As a normal user, mplayer produces many of the same
errors shown in the aplay -l command and fails to produce any
audio.

I ran strace -e trace=open,close,read,write and the good
trace wasn't all that much different from the bad trace.

Any idea as to what to look at next?

Thank you.

Martin McCormick


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205151127.q4fbrhyi079...@x.it.okstate.edu

Re: Problem with file perms

[Rodrigo Cosme]

Well, if the problem happens again I'll try that. For now I couldn't help
but use the good and old reinstall. But thanks to you all for the help.

On Wed, Nov 5, 2008 at 7:47 PM, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]
> wrote:

> On Tuesday 04 November 2008, "Rodrigo Cosme" <[EMAIL PROTECTED]> wrote
> about 'Problem with file perms':
> > Executing "ls -l" inside
> > /var/run I get:
> >
> >?- ? ? ? ?  ? klogd.pid
> >?- ? ? ? ?  ? syslogd.pid
> >drwxr-xr-x 2 root  root   4096   Jul   10   00:07  sshd
> >(and so on)
>
> If you are getting this output as root, I'd fsck your filesystem.
>
> It's also possible that extended attributes are tripping up ls.  I've not
> dealt with them myself, but I believe there's as lsattr command for
> viewing them and a chattr command for modifying them.
> --
> Boyd Stephen Smith Jr. ,= ,-_-. =.
> [EMAIL PROTECTED]  ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-'
> http://iguanasuicide.org/  \_/
>



-- 
__
Rodrigo de Castro Cosme
Ciência da Computação - Universidade Federal do Espírito Santo
Suporte mailing list - [EMAIL PROTECTED]
MSN - [EMAIL PROTECTED]

Re: Problem with file perms

[s. keeling]

Boyd Stephen Smith Jr. <[EMAIL PROTECTED]>:
>  On Tuesday 04 November 2008, "Rodrigo Cosme" <[EMAIL PROTECTED]> wrote=20
>  about 'Problem with file perms':
> > Executing "ls -l" inside
> > /var/run I get:
> >
> >?- ? ? ? ?  ? klogd.pid
> >?- ? ? ? ?  ? syslogd.pid
> >drwxr-xr-x 2 root  root   4096   Jul   10   00:07  sshd
> >(and so on)
> 
>  If you are getting this output as root, I'd fsck your filesystem.

Agree.  Those are all 644 on my etch system (rw-r--r--), and that does
appear to be fs confusion.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://blinkynet.net/comp/uip5.html  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem with file perms

[Boyd Stephen Smith Jr.]

On Tuesday 04 November 2008, "Rodrigo Cosme" <[EMAIL PROTECTED]> wrote 
about 'Problem with file perms':
> Executing "ls -l" inside
> /var/run I get:
>
>?- ? ? ? ?  ? klogd.pid
>?- ? ? ? ?  ? syslogd.pid
>drwxr-xr-x 2 root  root   4096   Jul   10   00:07  sshd
>(and so on)

If you are getting this output as root, I'd fsck your filesystem.

It's also possible that extended attributes are tripping up ls.  I've not 
dealt with them myself, but I believe there's as lsattr command for 
viewing them and a chattr command for modifying them.
-- 
Boyd Stephen Smith Jr. ,= ,-_-. =. 
[EMAIL PROTECTED]  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy   `-'(. .)`-' 
http://iguanasuicide.org/  \_/ 


signature.asc
Description: This is a digitally signed message part.

Problem with file perms

[Rodrigo Cosme]

Hi, all.

Here is the deal. I tried to restart syslogd after a minor change in the
configuration file and for some reason the log daemon won't start anymore.
The initialization messages  show that there's something wrong with two
files: klogd.pid and syslogd.pid. Executing "ls -l" inside /var/run I get:

?- ? ? ? ?  ? klogd.pid
?- ? ? ? ?  ? syslogd.pid
drwxr-xr-x 2 root  root   4096   Jul   10   00:07  sshd
(and so on)

I can't  write, remove or do anything with these archives. As you can see,
if I exec "ls" they are listed, but if I exec "vim /var/run", these files
are not there.

Can anyone point me in the rigth direction?

-- 
__
Rodrigo de Castro Cosme
Ciência da Computação - Universidade Federal do Espírito Santo
Suporte mailing list - [EMAIL PROTECTED]
MSN - [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Andrei Popescu]

Kent West <[EMAIL PROTECTED]> wrote:

> Andrei Popescu wrote:
> > Kent West <[EMAIL PROTECTED]> wrote:
> >
> >   
> >> A few days ago xlinks2 was mentioned on this list and I decided to
> >> give it a try.
> >>
> >> When I try to run it from within X as a normal user, no problem.
> >>
> >> When I try to run it outside of X as root, no problem.
> >>
> >> When I try to run it outside of X as a normal user, I get an error
> >> about opening /dev/tty0 because of permission issues.
> >>
> >> [EMAIL PROTECTED]:~$ ls -l /dev/tty0
> >> crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0
> >>
> >> I could change the group to "tty" or something and then add my
> >> normal user into that group, but is there perhaps a
> >> better/safer/more-canonical way?
> >> 
> >
> > Interesting. On my system:
> >
> > ls -l /dev/tty2
> > crw--- 1 amp77 tty 4, 2 2007-03-27 23:20 /dev/tty2
> >
> > What are you running (stable, testing, ...?)
> >   
> 
> Etch
> 
> [EMAIL PROTECTED]:~$ ls -l /dev/tty2
> crw--- 1 westk tty 4, 2 2007-03-26 14:13 /dev/tty2
> 
> On this box, tty2 is the only file owned by me and the group tty; all 
> others are root.root (until you get to the tty[a..z] group, which is 
> then root.tty).
> 

I only checked tty2 because that's where I'm logged in and xlinks2
works (no mouse, but still). Or am I missing something? Just for
completeness:

$ ls -l /dev/tty0
crw-rw 1 amp77 amp77 4, 0 2007-03-27 22:03 /dev/tty0

$ id
uid=1000(amp77) gid=1000(amp77)
groups=20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),1000(amp77)

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Kent West]

Andrei Popescu wrote:

Kent West <[EMAIL PROTECTED]> wrote:

  

A few days ago xlinks2 was mentioned on this list and I decided to
give it a try.

When I try to run it from within X as a normal user, no problem.

When I try to run it outside of X as root, no problem.

When I try to run it outside of X as a normal user, I get an error
about opening /dev/tty0 because of permission issues.

[EMAIL PROTECTED]:~$ ls -l /dev/tty0
crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0

I could change the group to "tty" or something and then add my normal 
user into that group, but is there perhaps a

better/safer/more-canonical way?



Interesting. On my system:

ls -l /dev/tty2
crw--- 1 amp77 tty 4, 2 2007-03-27 23:20 /dev/tty2

What are you running (stable, testing, ...?)
  


Etch

[EMAIL PROTECTED]:~$ ls -l /dev/tty2
crw--- 1 westk tty 4, 2 2007-03-26 14:13 /dev/tty2

On this box, tty2 is the only file owned by me and the group tty; all 
others are root.root (until you get to the tty[a..z] group, which is 
then root.tty).


--
Kent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Andrei Popescu]

Kent West <[EMAIL PROTECTED]> wrote:

> A few days ago xlinks2 was mentioned on this list and I decided to
> give it a try.
> 
> When I try to run it from within X as a normal user, no problem.
> 
> When I try to run it outside of X as root, no problem.
> 
> When I try to run it outside of X as a normal user, I get an error
> about opening /dev/tty0 because of permission issues.
> 
> [EMAIL PROTECTED]:~$ ls -l /dev/tty0
> crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0
> 
> I could change the group to "tty" or something and then add my normal 
> user into that group, but is there perhaps a
> better/safer/more-canonical way?

Interesting. On my system:

ls -l /dev/tty2
crw--- 1 amp77 tty 4, 2 2007-03-27 23:20 /dev/tty2

What are you running (stable, testing, ...?)

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Kent West]

Cassiano Leal wrote:
Try 'links2 -g'. Since I've never used xlinks2, I can't say wether 
they're the same thing.


Worth a shot, though!



[EMAIL PROTECTED]:~$ cat /usr/bin/xlinks2
#!/bin/sh
links2 -g "$@"


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Cassiano Leal]

Kent West wrote:

Michael Pobega wrote:

On Mon, Mar 26, 2007 at 02:15:21PM -0500, Kent West wrote:
 
A few days ago xlinks2 was mentioned on this list and I decided to 
give it a try.


When I try to run it from within X as a normal user, no problem.

When I try to run it outside of X as root, no problem.

When I try to run it outside of X as a normal user, I get an error 
about opening /dev/tty0 because of permission issues.


[EMAIL PROTECTED]:~$ ls -l /dev/tty0
crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0

I could change the group to "tty" or something and then add my normal 
user into that group, but is there perhaps a 
better/safer/more-canonical way?





Kind of an OT question sorry, but how can you run xlinks2 outside of
X? I thought that TTY terminal sessions didn't support images?
  
It uses the fbdev device; pretty sweet. And fast! Of course, it has some 
limitations 




Try 'links2 -g'. Since I've never used xlinks2, I can't say wether 
they're the same thing.


Worth a shot, though!

Cassiano


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Kent West]

Michael Pobega wrote:

On Mon, Mar 26, 2007 at 02:15:21PM -0500, Kent West wrote:
  
A few days ago xlinks2 was mentioned on this list and I decided to give 
it a try.


When I try to run it from within X as a normal user, no problem.

When I try to run it outside of X as root, no problem.

When I try to run it outside of X as a normal user, I get an error about 
opening /dev/tty0 because of permission issues.


[EMAIL PROTECTED]:~$ ls -l /dev/tty0
crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0

I could change the group to "tty" or something and then add my normal 
user into that group, but is there perhaps a better/safer/more-canonical 
way?





Kind of an OT question sorry, but how can you run xlinks2 outside of
X? I thought that TTY terminal sessions didn't support images?
  
It uses the fbdev device; pretty sweet. And fast! Of course, it has some 
limitations 


--
Kent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /dev/tty perms for xlinks2

[Michael Pobega]

On Mon, Mar 26, 2007 at 02:15:21PM -0500, Kent West wrote:
> A few days ago xlinks2 was mentioned on this list and I decided to give 
> it a try.
> 
> When I try to run it from within X as a normal user, no problem.
> 
> When I try to run it outside of X as root, no problem.
> 
> When I try to run it outside of X as a normal user, I get an error about 
> opening /dev/tty0 because of permission issues.
> 
> [EMAIL PROTECTED]:~$ ls -l /dev/tty0
> crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0
> 
> I could change the group to "tty" or something and then add my normal 
> user into that group, but is there perhaps a better/safer/more-canonical 
> way?
> 

Kind of an OT question sorry, but how can you run xlinks2 outside of
X? I thought that TTY terminal sessions didn't support images?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

/dev/tty perms for xlinks2

[Kent West]

A few days ago xlinks2 was mentioned on this list and I decided to give 
it a try.


When I try to run it from within X as a normal user, no problem.

When I try to run it outside of X as root, no problem.

When I try to run it outside of X as a normal user, I get an error about 
opening /dev/tty0 because of permission issues.


[EMAIL PROTECTED]:~$ ls -l /dev/tty0
crw-rw 1 root root 4, 0 2007-03-07 10:04 /dev/tty0

I could change the group to "tty" or something and then add my normal 
user into that group, but is there perhaps a better/safer/more-canonical 
way?


Thanks!

--
Kent


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Basing new file permissions on current dir perms

[Mark Roach]

On Fri, 2004-01-09 at 14:05, Alex Malinovich wrote:
> On Fri, 2004-01-09 at 11:36, Monique Y. Herman wrote:
> > On 2004-01-09, Rob Sims penned:
[...]
> > > chmod g+s mydirectory
> > >
> > > Note that changing the directory's group will clear the sticky bit.
> > > -- Rob
> > >
> > 
> > That will not force rw access to group, though, right?  I think that was
> > part of the question the OP was asking.
> 
> Yes it was. :) This does indeed get the correct ownership on the files,
> but the files are still uneditable because they are made at 644 instead
> of 664 as I'd like. Any suggestions on this front?

There are two options:

1) set umask to 002 in the appropriate place (/etc/login.defs,
~.profile, /etc/profile)
2) use acls and do a "setfacl -md g:groupname:rwx dirname/"

-- 
Mark Roach


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Basing new file permissions on current dir perms

[Alex Malinovich]

On Fri, 2004-01-09 at 11:36, Monique Y. Herman wrote:
> On 2004-01-09, Rob Sims penned:
> > On Friday 09 January 2004 05:06 am, Alex Malinovich wrote:
> >> Lets say I have a directory called mydirectory. The permissions are
> >> as follows:
> >> 
> >> drwxrwxr-x root mygroup
> >
> > ...
> >
> >> What I want, is a way to force the default permissions for new files
> >> in this directory to be:
> >> 
> >> -rw-rw-r-- myuser mygroup
> >
> > chmod g+s mydirectory
> >
> > Note that changing the directory's group will clear the sticky bit.
> > -- Rob
> >
> 
> That will not force rw access to group, though, right?  I think that was
> part of the question the OP was asking.

Yes it was. :) This does indeed get the correct ownership on the files,
but the files are still uneditable because they are made at 644 instead
of 664 as I'd like. Any suggestions on this front?
-- 
Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837



signature.asc
Description: This is a digitally signed message part

Re: Basing new file permissions on current dir perms

[Monique Y. Herman]

On 2004-01-09, Rob Sims penned:
> On Friday 09 January 2004 05:06 am, Alex Malinovich wrote:
>> Lets say I have a directory called mydirectory. The permissions are
>> as follows:
>> 
>> drwxrwxr-x root mygroup
>
> ...
>
>> What I want, is a way to force the default permissions for new files
>> in this directory to be:
>> 
>> -rw-rw-r-- myuser mygroup
>
> chmod g+s mydirectory
>
> Note that changing the directory's group will clear the sticky bit.
> -- Rob
>

That will not force rw access to group, though, right?  I think that was
part of the question the OP was asking.

-- 
monique


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Basing new file permissions on current dir perms

[Rob Sims]

On Friday 09 January 2004 05:06 am, Alex Malinovich wrote:
> Lets say I have a directory called mydirectory. The permissions are as
> follows:
> 
> drwxrwxr-x root mygroup

...

> What I want, is a way to force the default permissions for new files in
> this directory to be:
> 
> -rw-rw-r-- myuser mygroup

chmod g+s mydirectory

Note that changing the directory's group will clear the sticky bit.
--
Rob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Basing new file permissions on current dir perms

[Alex Malinovich]

This seems like it should be simple enough, yet it's not working that
way. Here's essentially what I want to do:

Lets say I have a directory called mydirectory. The permissions are as
follows:

drwxrwxr-x root mygroup

If a user who is part of mygroup, say myuser, creates a new file within
mydirectory, the permissions of the file end up being:

-rw-r--r-- myuser myuser

What I want, is a way to force the default permissions for new files in
this directory to be:

-rw-rw-r-- myuser mygroup

This is meant to be a shared directory with shared files. Unfortunately,
while it's easy enough to create a shared directory, creating shared
files in it by default doesn't seem to be nearly as easy. I set up a
shared directory for myself and my roommates to use, but they are very
lazy about resetting the permissions on files they add, so I end up
being unable to modify them (without going in as root). It would be
really nice to be able to automatically set the permissions to the
correct values whenever they create a file. Any help is greatly
appreciated.
-- 
Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837



signature.asc
Description: This is a digitally signed message part

struggling with mysql perms (woody)

[justin cunningham]

I created two users with grant; obdba with select,insert,index,file and
other privileges and obdbu with select only privileges.  Flushed
privileges.  Mysqlaccess shows the correct perms for database
'properties' (the only database) for each user although when I try
logging in as either user to test I get access denied every time.  what
did I do wrong?  here's the output of mysqlaccess if it helps. 

Thank you, justin

oba:~# mysqlaccess obdba properties
Could not open outputfile ~/mysqlaccess.log for debugging-info
mysqlaccess Version 2.06, 20 Dec 2000
By RUG-AIV, by Yves Carlier ([EMAIL PROTECTED])
Changes by Steve Harvey ([EMAIL PROTECTED])
This software comes with ABSOLUTELY NO WARRANTY.

Access-rights
for USER 'obdba', from HOST 'localhost', to DB 'properties'
+-+---+ +-+---+
| Select_priv | Y | | Shutdown_priv   | N |
| Insert_priv | Y | | Process_priv| N |
| Update_priv | N | | File_priv   | Y |
| Delete_priv | Y | | Grant_priv  | N |
| Create_priv | N | | References_priv | N |
| Drop_priv   | N | | Index_priv  | Y |
| Reload_priv | N | | Alter_priv  | Y |
+-+---+ +-+---+
NOTE:A password is required for user `obdba' :-(

The following rules are used:
 db:
'localhost','properties','obdba','Y','Y','N','Y','N','N','N','N','Y','Y'
 host  : 'Not processed: host-field is not empty in db-table.'
 user  :
'localhost','obdba','255c3b646e0fb525','N','N','N','N','N','N','N','N','
N','Y','N','N','N','N'

oba:~# mysqlaccess obdbu properties
Could not open outputfile ~/mysqlaccess.log for debugging-info
mysqlaccess Version 2.06, 20 Dec 2000
By RUG-AIV, by Yves Carlier ([EMAIL PROTECTED])
Changes by Steve Harvey ([EMAIL PROTECTED])
This software comes with ABSOLUTELY NO WARRANTY.

Access-rights
for USER 'obdbu', from HOST 'localhost', to DB 'properties'
+-+---+ +-+---+
| Select_priv | Y | | Shutdown_priv   | N |
| Insert_priv | N | | Process_priv| N |
| Update_priv | N | | File_priv   | N |
| Delete_priv | N | | Grant_priv  | N |
| Create_priv | N | | References_priv | N |
| Drop_priv   | N | | Index_priv  | N |
| Reload_priv | N | | Alter_priv  | N |
+-+---+ +-+---+
NOTE:A password is required for user `obdbu' :-(

The following rules are used:
 db: 'No matching rule'
 host  : 'Not processed: host-field is not empty in db-table.'
 user  :
'localhost','obdbu','62ee70220efa4cb8','Y','N','N','N','N','N','N','N','
N','N','N','N','N','N'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]