On Mon, Aug 15, 2016 at 01:09:20AM +0200, Martin Bammer wrote:
> Does Windows save usernames for access rights?
No, NTFS permissions are tied to SIDs which are like UNIX UIDs/GIDs but
unique for non-default entities, because they include the computer SID
(those may be non-unique if a system was clo
> [...]
In the original scenario, the concern was was with shared media having
uid/gid numbers that don't match what's on the system. In that
scenario, this was viewed as a security concern. This is not a
security concern because once someone has physical access to your
unencrypted data, it's no l
On 2016-08-15 01:09:20 +0200 (+0200), Martin Bammer wrote:
[...]
> I thought that the IDs for system services are fixed. Static ID
> mapping is a nice idea which would be helpful for system services.
[...]
Some of them are fixed: https://wiki.debian.org/SystemGroups
There are compiled-in defaults
Adam Borowski writes ("Re: UID and GID generation"):
> Actually, I do like this idea; obviously with reasoning contrary to the
> original report. In any small organization or a family, where you have an
> ad hoc set of machines without centralized user management, it is nice t
>
> For all such situations a workaround exists. Still I've been wondering
> for years why appearently nobody else considers this a problem. So I
> patched adduser to determine the user (also: group) ID from a static
> "acount name"<->"ID" mapping. It's in the BTS somewhere eight years
> ago, and
Christoph Biedl wrote...
> So I patched adduser to determine the user (also: group) ID from a
> static "acount name"<->"ID" mapping. It's in the BTS somewhere eight
> years ago,
FTR: #243929
signature.asc
Description: Digital signature
nstallations was painful but worth it, YMMV.
> So my suggestion would be to change the default behavior of UID and
> GID generation to hash value calculation. Has values are computed by
> the user and group names as 32bit values on Debian (31bit on Red
> Hat). The minimum and maximum va
> Actually, I do like this idea; obviously with reasoning contrary to the
> original report. In any small organization or a family, where you have an
> ad hoc set of machines without centralized user management, it is nice to
> have consistent uids.
>
> This helps with cases like moving a disk ar
> Actually, I do like this idea; obviously with reasoning contrary to the
> original report. In any small organization or a family, where you have an
> ad hoc set of machines without centralized user management, it is nice to
> have consistent uids.
>
> This helps with cases like moving a disk ar
no matter which of you originally set that box up, this problem is avoided.
Obviously, it doesn't scale well past a handful of users, but by then anyone
sane will keep things organized in some way.
> >So my suggestion would be to change the default behavior of UID and GID
> >gen
use EFS, which
people generally don't).
So my suggestion would be to change the default behavior of UID and
GID generation to hash value calculation.
I think that's a terrible idea. It does not solve the problem you are
trying to solve and it creates even more of a mess with us
efault behavior of UID and GID
generation to hash value calculation. Has values are computed by the user and
group names as 32bit values on Debian (31bit on Red Hat). The minimum and
maximum values should be configurable.
Here an example how UIDs and GIDs can be generated:
uidGen = h
esign issue!
So my suggestion would be to change the default behavior of UID and GID
generation to hash value calculation. Has values are computed by the user and
group names as 32bit values on Debian (31bit on Red Hat). The minimum and
maximum values should be configurable.
Here an example how UI
13 matches
Mail list logo
